-
Description: REST client for Ruby (aka rest-client) before 1.8.0 allows remote attackers to conduct session fixation attacks or obtain sensitive cookie information by leveraging passage of cookies set in a response to a redirect.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python-requests > 0-0 (version in image is 2.24.0-8.26.1).
-
Description: Salt before 2015.8.11 allows deleted minions to read or write to minions with the same id, related to caching.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- salt > 0-0 (version in image is 3000-74.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: zlib is a Ruby interface for the zlib compression/decompression library. Versions 3.0.0 and below, 3.1.0, 3.1.1, 3.2.0 and 3.2.1 contain a buffer overflow vulnerability in the Zlib::GzipReader. The zstream_buffer_ungets function prepends caller-provided bytes ahead of previously produced output but fails to guarantee the backing Ruby string has enough capacity before the memmove shifts the existing data. This can lead to memory corruption when the buffer length exceeds capacity. This issue has been fixed in versions 3.0.1, 3.1.2 and 3.2.3.
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: digital: Bounds check NFC-A cascade depth in SDD response handlerThe NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3or 4 bytes to target->nfcid1 on each round, but the number of cascaderounds is controlled entirely by the peer device. The peer sets thecascade tag in the SDD_RES (deciding 3 vs 4 bytes) and thecascade-incomplete bit in the SEL_RES (deciding whether another roundfollows).ISO 14443-3 limits NFC-A to three cascade levels and target->nfcid1 issized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driveractually enforces this. This means a malicious peer can keep thecascade running, writing past the heap-allocated nfc_target with eachround.Fix this by rejecting the response when the accumulated UID would exceedthe buffer.Commit e329e71013c9 ("NFC: nci: Bounds check struct nfc_target arrays")fixed similar missing checks against the same field on the NCI 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: llcp: add missing return after LLCP_CLOSED checksIn nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socketstate is LLCP_CLOSED, the code correctly calls release_sock() andnfc_llcp_sock_put() but fails to return. Execution falls through tothe remainder of the function, which calls release_sock() andnfc_llcp_sock_put() again. This results in a double release_sock()and a refcount underflow via double nfc_llcp_sock_put(), leading toa use-after-free.Add the missing return statements after the LLCP_CLOSED branchesin both functions to prevent the fall-through.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: validate the whole DACL before rewriting it in cifsaclbuild_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from aserver-supplied dacloffset and then use the incoming ACL to rebuild thechmod/chown security descriptor.The original fix only checked that the struct smb_acl header fits beforereading dacl_ptr->size or dacl_ptr->num_aces. That avoids the immediateheader-field OOB read, but the rewrite helpers still walk ACEs based onpdacl->num_aces with no structural validation of the incoming DACL body.A malicious server can return a truncated DACL that still contains aheader, claims one or more ACEs, and then drivereplace_sids_and_copy_aces() or set_chmod_dacl() past the validatedextent while they compare or copy attacker-controlled ACEs.Factor the DACL structural checks into validate_dacl(), extend them tovalidate each ACE against the DACL bounds, and use the shared validatorbefore the chmod/chown rebuild paths. parse_dacl() reuses the samevalidator so the read-side parser and write-side rewrite paths agree onwhat constitutes a well-formed incoming DACL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: esp: avoid in-place decrypt on shared skb fragsMSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCPmarks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(),so later paths that may modify packet data can first make a privatecopy. The IPv4/IPv6 datagram append paths did not set this flag whensplicing pages into UDP skbs.That leaves an ESP-in-UDP packet made from shared pipe pages lookinglike an ordinary uncloned nonlinear skb. ESP input then takes the no-COWfast path for uncloned skbs without a frag_list and decrypts in placeover data that is not owned privately by the skb.Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matchingTCP. Also make ESP input fall back to skb_cow_data() when the flag ispresent, so ESP does not decrypt externally backed frags in place.Private nonlinear skb frags still use the existing fast path.This intentionally does not change ESP output. In esp_output_head(),the path that appends the ESP trailer to existing skb tailroom withoutcalling skb_cow_data() is not reachable for nonlinear skbs:skb_tailroom() returns zero when skb->data_len is nonzero, while ESPtailen is positive. Thus ESP output will either use the separatedestination-frag path or fall back to skb_cow_data().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.307.1 (version in image is 4.12.14-122.302.1).
-
Description: Unknown.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.307.1 (version in image is 4.12.14-122.302.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.68.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: The Salt-SSH pre-flight option copies the script to the target at a predictable path, which allows an attacker to force Salt-SSH to run their script. If an attacker has access to the target VM and knows the path to the pre-flight script before it runs they can ensure Salt-SSH runs their script with the privileges of the user running Salt-SSH. Do not make the copy path on the target predictable and ensure we check return codes of the scp command if the copy fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- salt > 0-0 (version in image is 3000-74.1).
-
Description: The Fiddle::Handle implementation in ext/fiddle/handle.c in Ruby before 2.0.0-p648, 2.1 before 2.1.8, and 2.2 before 2.2.4, as distributed in Apple OS X before 10.11.4 and other products, mishandles tainting, which allows context-dependent attackers to execute arbitrary code or cause a denial of service (application crash) via a crafted string, related to the DL module and the libffi library. NOTE: this vulnerability exists because of a CVE-2009-5147 regression.
Packages affected:
- sles-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.302.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: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix heap overflow in NFSv4.0 LOCK replay cacheThe NFSv4.0 replay cache uses a fixed 112-byte inline buffer(rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses.This size was calculated based on OPEN responses and does not accountfor LOCK denied responses, which include the conflicting lock owner asa variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT).When a LOCK operation is denied due to a conflict with an existing lockthat has a large owner, nfsd4_encode_operation() copies the full encodedresponse into the undersized replay buffer via read_bytes_from_xdr_buf()with no bounds check. This results in a slab-out-of-bounds write of upto 944 bytes past the end of the buffer, corrupting adjacent heap memory.This can be triggered remotely by an unauthenticated attacker with twocooperating NFSv4.0 clients: one sets a lock with a large owner string,then the other requests a conflicting lock to provoke the denial.We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a fullopaque, but that would increase the size of every stateowner, when mostlockowners are not that large.Instead, fix this by checking the encoded response length againstNFSD4_REPLAY_ISIZE before copying into the replay buffer. If theresponse is too large, set rp_buflen to 0 to skip caching the replaypayload. The status is still cached, and the client already received thecorrect response on the original request.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: A flaw in GnuTLS DTLS handshake parsing allows malformed fragments with zero length and non-zero offset, leading to an integer underflow during reassembly and resulting in an out-of-bounds read. This issue is remotely exploitable and may cause information disclosure or denial of service.
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:netfilter: xt_tcpmss: check remaining length before reading optlenQuoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length. If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following 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.302.1).
-
Description: XML::LibXML versions through 2.0210 for Perl read out-of-bounds heap memory when parsing XML node names containing truncated UTF-8 byte sequences.A node name ending in the middle of a multi byte UTF-8 sequence causes the parser to read past the end of the input string into adjacent heap memory.Any Perl process that passes attacker controlled strings to XML::LibXML's DOM node-name methods can reach this path on the default API. The likely consequence is a crash, causing denial of service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- perl-XML-LibXML > 0-0 (version in image is 2.0019-6.3.5).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO pathsmb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTLand the default QUERY_INFO path. The QUERY_INFO branch clampsqi.input_buffer_length to the server-reported OutputBufferLength and thencopies qi.input_buffer_length bytes from qi_rsp->Buffer to userspace, butit never verifies that the flexible-array payload actually fits withinrsp_iov[1].iov_len.A malicious server can return OutputBufferLength larger than the actualQUERY_INFO response, causing copy_to_user() to walk past the responsebuffer and expose adjacent kernel heap to userspace.Guard the QUERY_INFO copy with a bounds check on the actual Bufferpayload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length)rather than an open-coded addition so the guard cannot overflow on32-bit builds.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have an authorization bypass resulting from improper input validation of the HTTP/2 `:path` pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present. This affects gRPC-Go servers that use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`; AND that have a security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server. The fix in version 1.79.3 ensures that any request with a `:path` that does not start with a leading slash is immediately rejected with a `codes.Unimplemented` error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string. While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods: Use a validating interceptor (recommended mitigation); infrastructure-level normalization; and/or policy hardening.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- google-guest-agent > 0-0 (version in image is 20250506.01-1.53.1).
-
Description: ERB is a templating system for Ruby. Ruby 2.7.0 (before ERB 2.2.0 was published on rubygems.org) introduced an `@_init` instance variable guard in `ERB#result` and `ERB#run` to prevent code execution when an ERB object is reconstructed via `Marshal.load` (deserialization). However, three other public methods that also evaluate `@src` via `eval()` were not given the same guard: `ERB#def_method`, `ERB#def_module`, and `ERB#def_class`. An attacker who can trigger `Marshal.load` on untrusted data in a Ruby application that has `erb` loaded can use `ERB#def_module` (zero-arg, default parameters) as a code execution sink, bypassing the `@_init` protection entirely. ERB 4.0.3.1, 4.0.4.1, 6.0.1.1, and 6.0.4 patch the issue.
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:Bluetooth: SMP: force responder MITM requirements before building the pairing responsesmp_cmd_pairing_req() currently builds the pairing response from theinitiator auth_req before enforcing the local BT_SECURITY_HIGHrequirement. If the initiator omits SMP_AUTH_MITM, the response canalso omit it even though the local side still requires MITM.tk_request() then sees an auth value without SMP_AUTH_MITM and mayselect JUST_CFM, making method selection inconsistent with the pairingpolicy the responder already enforces.When the local side requires HIGH security, first verify that MITM canbe achieved from the IO capabilities and then force SMP_AUTH_MITM in theresponse in both rsp.auth_req and auth. This keeps the responder auth bitsand later method selection aligned.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: Use-after-free (UAF) was possible in the `lzma.LZMADecompressor`, `bz2.BZ2Decompressor`, and `gzip.GzipFile` when a memory allocation fails with a `MemoryError` and the decompression instance is re-used. This scenario can be triggered if the process is under memory pressure. The fix cleans up the dangling pointer in this specific error condition.The vulnerability is only present if the program re-uses decompressor instances across multiple decompression calls even after a `MemoryError` is raised during decompression. Using the helper functions to one-shot decompress data such as `lzma.decompress()`, `bz2.decompress()`, `gzip.decompress()`, and `zlib.decompress()` are not affected as a new decompressor instance is used per call. If the decompressor instance is not re-used after an error condition, this usage is similarly not vulnerable.
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.74.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 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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: smscufx: properly copy ioctl memory to kernelspaceThe UFX_IOCTL_REPORT_DAMAGE ioctl does not properly copy data fromuserspace to kernelspace, and instead directly references the memory,which can cause problems if invalid data is passed from userspace. Fixthis all up by correctly copying the memory before accessing it withinthe 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: HIDP: Fix possible UAFThis fixes the following trace caused by not dropping l2cap_connreference when user->remove callback is called:[ 97.809249] l2cap_conn_free: freeing conn ffff88810a171c00[ 97.809907] CPU: 1 UID: 0 PID: 1419 Comm: repro_standalon Not tainted 7.0.0-rc1-dirty #14 PREEMPT(lazy)[ 97.809935] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014[ 97.809947] Call Trace:[ 97.809954] [ 97.809961] dump_stack_lvl (lib/dump_stack.c:122)[ 97.809990] l2cap_conn_free (net/bluetooth/l2cap_core.c:1808)[ 97.810017] l2cap_conn_del (./include/linux/kref.h:66 net/bluetooth/l2cap_core.c:1821 net/bluetooth/l2cap_core.c:1798)[ 97.810055] l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7347 (discriminator 1) net/bluetooth/l2cap_core.c:7340 (discriminator 1))[ 97.810086] ? __pfx_l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7341)[ 97.810117] hci_conn_hash_flush (./include/net/bluetooth/hci_core.h:2152 (discriminator 2) net/bluetooth/hci_conn.c:2644 (discriminator 2))[ 97.810148] hci_dev_close_sync (net/bluetooth/hci_sync.c:5360)[ 97.810180] ? __pfx_hci_dev_close_sync (net/bluetooth/hci_sync.c:5285)[ 97.810212] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 97.810242] ? up_write (./arch/x86/include/asm/atomic64_64.h:87 (discriminator 5) ./include/linux/atomic/atomic-arch-fallback.h:2852 (discriminator 5) ./include/linux/atomic/atomic-long.h:268 (discriminator 5) ./include/linux/atomic/atomic-instrumented.h:3391 (discriminator 5) kernel/locking/rwsem.c:1385 (discriminator 5) kernel/locking/rwsem.c:1643 (discriminator 5))[ 97.810267] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 97.810290] ? rcu_is_watching (./arch/x86/include/asm/atomic.h:23 ./include/linux/atomic/atomic-arch-fallback.h:457 ./include/linux/context_tracking.h:128 kernel/rcu/tree.c:752)[ 97.810320] hci_unregister_dev (net/bluetooth/hci_core.c:504 net/bluetooth/hci_core.c:2716)[ 97.810346] vhci_release (drivers/bluetooth/hci_vhci.c:691)[ 97.810375] ? __pfx_vhci_release (drivers/bluetooth/hci_vhci.c:678)[ 97.810404] __fput (fs/file_table.c:470)[ 97.810430] task_work_run (kernel/task_work.c:235)[ 97.810451] ? __pfx_task_work_run (kernel/task_work.c:201)[ 97.810472] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 97.810495] ? do_raw_spin_unlock (./include/asm-generic/qspinlock.h:128 (discriminator 5) kernel/locking/spinlock_debug.c:142 (discriminator 5))[ 97.810527] do_exit (kernel/exit.c:972)[ 97.810547] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 97.810574] ? __pfx_do_exit (kernel/exit.c:897)[ 97.810594] ? lock_acquire (kernel/locking/lockdep.c:470 (discriminator 6) kernel/locking/lockdep.c:5870 (discriminator 6) kernel/locking/lockdep.c:5825 (discriminator 6))[ 97.810616] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 97.810639] ? do_raw_spin_lock (kernel/locking/spinlock_debug.c:95 (discriminator 4) kernel/locking/spinlock_debug.c:118 (discriminator 4))[ 97.810664] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 97.810688] ? find_held_lock (kernel/locking/lockdep.c:5350 (discriminator 1))[ 97.810721] do_group_exit (kernel/exit.c:1093)[ 97.810745] get_signal (kernel/signal.c:3007 (discriminator 1))[ 97.810772] ? security_file_permission (./arch/x86/include/asm/jump_label.h:37 security/security.c:2366)[ 97.810803] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 97.810826] ? vfs_read (fs/read_write.c:555)[ 97.810854] ? __pfx_get_signal (kernel/signal.c:2800)[ 97.810880] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 97.810905] ? __pfx_vfs_read (fs/read_write.c:555)[ 97.810932] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 97.810960] arch_do_signal_or_restart (arch/---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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix double-free of smc_spd_priv when tee() duplicates splice pipe buffersmc_rx_splice() allocates one smc_spd_priv per pipe_buffer and storesthe pointer in pipe_buffer.private. The pipe_buf_operations for thesebuffers used .get = generic_pipe_buf_get, which only increments the pagereference count when tee(2) duplicates a pipe buffer. The smc_spd_privpointer itself was not handled, so after tee() both the original and thecloned pipe_buffer share the same smc_spd_priv *.When both pipes are subsequently released, smc_rx_pipe_buf_release() iscalled twice against the same object: 1st call: kfree(priv) sock_put(sk) smc_rx_update_cons() [correct] 2nd call: kfree(priv) sock_put(sk) smc_rx_update_cons() [UAF]KASAN reports a slab-use-after-free in smc_rx_pipe_buf_release(), whichthen escalates to a NULL-pointer dereference and kernel panic viasmc_rx_update_consumer() when it chases the freed priv->smc pointer: BUG: KASAN: slab-use-after-free in smc_rx_pipe_buf_release+0x78/0x2a0 Read of size 8 at addr ffff888004a45740 by task smc_splice_tee_/74 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x650 kasan_report+0xc6/0x100 smc_rx_pipe_buf_release+0x78/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:smc_rx_update_consumer+0x8d/0x350 Call Trace: smc_rx_pipe_buf_release+0x121/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exceptionBeyond the memory-safety problem, duplicating an SMC splice buffer issemantically questionable: smc_rx_update_cons() would advance theconsumer cursor twice for the same data, corrupting receive-windowaccounting. A refcount on smc_spd_priv could fix the double-free, butthe cursor-accounting issue would still need to be addressed separately.The .get callback is invoked by both tee(2) and splice_pipe_to_pipe()for partial transfers; both will now return -EFAULT. Users who needto duplicate SMC socket data must use a copy-based read 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bcache: fix cached_dev.sb_bio use-after-free and crashIn our production environment, we have received multiple crash reportsregarding libceph, which have caught our attention:```[6888366.280350] Call Trace:[6888366.280452] blk_update_request+0x14e/0x370[6888366.280561] blk_mq_end_request+0x1a/0x130[6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd][6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd][6888366.280903] __complete_request+0x22/0x70 [libceph][6888366.281032] osd_dispatch+0x15e/0xb40 [libceph][6888366.281164] ? inet_recvmsg+0x5b/0xd0[6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph][6888366.281405] ceph_con_process_message+0x79/0x140 [libceph][6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph][6888366.281661] ceph_con_workfn+0x329/0x680 [libceph]```After analyzing the coredump file, we found that the address ofdc->sb_bio has been freed. We know that cached_dev is only freed when itis stopped.Since sb_bio is a part of struct cached_dev, rather than an alloc everytime. If the device is stopped while writing to the superblock, thereleased address will be accessed at endio.This patch hopes to wait for sb_write to complete in cached_dev_free.It should be noted that we analyzed the cause of the problem, then tellall details to the QWEN and adopted the modifications it made.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: ctxfi: Limit PTP to a single pageCommit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256playback streams, but the additional pages are not used by the cardcorrectly. The CT20K2 hardware already has multiple VMEM_PTPALregisters, but using them separately would require refactoring theentire virtual memory allocation logic.ct_vm_map() always uses PTEs in vm->ptp[0].area regardless ofCT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). Whenaggregate memory allocations exceed this limit, ct_vm_map() tries toaccess beyond the allocated space and causes a page fault: BUG: unable to handle page fault for address: ffffd4ae8a10a000 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi] Call Trace: atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7eRevert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_countremain 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_uac1_legacy: validate control request sizef_audio_complete() copies req->length bytes into a 4-byte stackvariable: u32 data = 0; memcpy(&data, req->buf, req->length);req->length is derived from the host-controlled USB request path,which can lead to a stack out-of-bounds write.Validate req->actual against the expected payload size for thesupported control selectors and decode only the expected amountof data.This avoids copying a host-influenced length into a fixed-sizestack object.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain()In the drain loop, the local variable 'runtime' is reassigned to alinked stream's runtime (runtime = s->runtime at line 2157). Afterreleasing the stream lock at line 2169, the code accessesruntime->no_period_wakeup, runtime->rate, and runtime->buffer_size(lines 2170-2178) - all referencing the linked stream's runtime withoutany lock or refcount protecting its lifetime.A concurrent close() on the linked stream's fd triggerssnd_pcm_release_substream() -> snd_pcm_drop() -> pcm_release_private()-> snd_pcm_unlink() -> snd_pcm_detach_substream() -> kfree(runtime).No synchronization prevents kfree(runtime) from completing while thedrain path dereferences the stale pointer.Fix by caching the needed runtime fields (no_period_wakeup, rate,buffer_size) into local variables while still holding the stream lock,and using the cached values after the lock is 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.302.1).
-
Description: Vim is an open source, command line text editor. Prior to 9.2.0479, a command injection vulnerability exists in tar#Vimuntar() inruntime/autoload/tar.vim when decompressing .tgz archives on Unix-like systems. The function builds :!gunzip and :!gzip -d commands using shellescape(tartail) without the {special} flag, allowing a crafted archive filename to trigger Vim cmdline-special expansion and execute shell commands in the user's context. This vulnerability is fixed in 9.2.0479.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- vim > 0-0 (version in image is 9.2.0280-17.62.1).
-
Description: A flaw was found in binutils. A heap-buffer-overflow vulnerability exists when processing a specially crafted XCOFF (Extended Common Object File Format) object file during linking. A local attacker could trick a user into processing this malicious file, which could lead to arbitrary code execution, allowing the attacker to run unauthorized commands, or cause a denial of service, making the system unavailable.
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 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: 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.2.0280-17.62.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:smb: client: require a full NFS mode SID before reading mode bitsparse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFSmode SID and reads sid.sub_auth[2] to recover the mode bits.That assumes the ACE carries three subauthorities, but compare_sids()only compares min(a, b) subauthorities. A malicious server can returnan ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which stillmatches sid_unix_NFS_mode and then drives the sub_auth[2] read fourbytes past the end of the ACE.Require num_subauth >= 3 before treating the ACE as an NFS mode SID.This keeps the fix local to the special-SID mode path without changingcompare_sids() semantics for the rest of cifsacl.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue. All OpenSSL 1.1.1 versions are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1-1.1.1j).
Packages affected:
- 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: 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.68.1).
-
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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix use-after-free in l2cap_unregister_userAfter commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list inhci_chan_del"), l2cap_conn_del() uses conn->lock to protect access toconn->users. However, l2cap_register_user() and l2cap_unregister_user()don't use conn->lock, creating a race condition where these functions canaccess conn->users and conn->hchan concurrently with l2cap_conn_del().This can lead to use-after-free and list corruption bugs, as reportedby syzbot.Fix this by changing l2cap_register_user() and l2cap_unregister_user()to use conn->lock instead of hci_dev_lock(), ensuring consistent lockingfor the l2cap_conn structure.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix possible deadlock between unlink and dio_end_io_writeocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem,while in ocfs2_dio_end_io_write, it acquires these locks in reverse order.This creates an ABBA lock ordering violation on lock classesocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] andocfs2_file_ip_alloc_sem_key.Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem):ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir ocfs2_expand_inline_dir down_write(&oi->ip_alloc_sem) <- Lock BLock Chain #1 (ip_alloc_sem -> orphan dir inode_lock):ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock ADeadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode)Since ip_alloc_sem is to protect allocation changes, which is unrelatedwith operations in ocfs2_del_inode_from_orphan. So moveocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: fix integer underflow in chain modeThe jumbo_frm() chain-mode implementation unconditionally computes len = nopaged_len - bmax;where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax isBUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit()decides to invoke jumbo_frm() based on skb->len (total length includingpage fragments): is_jumbo = stmmac_is_jumbo_frm(priv, skb->len, enh_desc);When a packet has a small linear portion (nopaged_len <= bmax) but alarge total length due to page fragments (skb->len > bmax), thesubtraction wraps as an unsigned integer, producing a huge len value(~0xFFFFxxxx). This causes the while (len != 0) loop to executehundreds of thousands of iterations, passing skb->data + bmax * ipointers far beyond the skb buffer to dma_map_single(). On IOMMU-lessSoCs (the typical deployment for stmmac), this maps arbitrary kernelmemory to the DMA engine, constituting a kernel memory disclosure andpotential memory corruption from hardware.Fix this by introducing a buf_len local variable clamped tomin(nopaged_len, bmax). Computing len = nopaged_len - buf_len is thenalways safe: it is zero when the linear portion fits within a singledescriptor, causing the while (len != 0) loop to be skipped naturally,and the fragment loop in stmmac_xmit() handles page fragments afterward.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: A heap buffer overflow vulnerability exists in the DTLS handshake fragment reassembly logic of GnuTLS. The issue arises in merge_handshake_packet() where incoming handshake fragments are matched and merged based solely on handshake type, without validating that the message_length field remains consistent across all fragments of the same logical message. An attacker can exploit this by sending crafted DTLS fragments with conflicting message_length values, causing the implementation to allocate a buffer based on a smaller initial fragment and subsequently write beyond its bounds using larger, inconsistent fragments. Because the merge operation does not enforce proper bounds checking against the allocated buffer size, this results in an out-of-bounds write on the heap. The vulnerability is remotely exploitable without authentication via the DTLS handshake path and can lead to application crashes or potential memory corruption.
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 OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users' expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).
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.34.1).
-
Description: The iconv() function in the GNU C Library versions 2.43 and earlier may crash due to an assertion failure when converting inputs from the IBM1390 or IBM1399 character sets, which may be used to remotely crash an application.This vulnerability can be trivially mitigated by removing the IBM1390 and IBM1399 character sets from systems that do not need them.
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.43.1).
-
Description: Unknown.
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:ip6_tunnel: clear skb2->cb[] in ip4ip6_err()Oskar Kjos reported the following problem.ip4ip6_err() calls icmp_send() on a cloned skb whose cb[] was writtenby the IPv6 receive path as struct inet6_skb_parm. icmp_send() passesIPCB(skb2) to __ip_options_echo(), which interprets that cb[] regionas struct inet_skb_parm (IPv4). The layouts differ: inet6_skb_parm.nhoffat offset 14 overlaps inet_skb_parm.opt.rr, producing a non-zero rrvalue. __ip_options_echo() then reads optlen from attacker-controlledpacket data at sptr[rr+1] and copies that many bytes into dopt->__data,a fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE).To fix this we clear skb2->cb[], as suggested by Oskar Kjos.Also add minimal IPv4 header validation (version == 4, ihl >= 5).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: validate bsscfg indices in IF eventsbrcmf_fweh_handle_if_event() validates the firmware-provided interfaceindex before it touches drvr->iflist[], but it still uses the rawbsscfgidx field as an array index without a matching range check.Reject IF events whose bsscfg index does not fit in drvr->iflist[]before indexing the interface array.[add missing wifi 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.302.1).
-
Description: urllib3 is an HTTP client library for Python. From 1.23 to before 2.7.0, cross-origin redirects followed from the low-level API via ProxyManager.connection_from_url().urlopen(..., assert_same_host=False) still forward these sensitive headers. This vulnerability is fixed in 2.7.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.48.4).
-
Description: `xml.parsers.expat` and `xml.etree.ElementTree` use insufficient entropy for Expat hash-flooding protection, which allows a crafted XML document to trigger hash flooding.\r\n\r\nFully mitigating this vulnerability requires both updating libexpat to 2.8.0 or later and applying this patch.
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.74.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 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.180.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.180.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: Improper isolation of shared resources within the CPU operation cache on Zen 2-based products could allow an attacker to corrupt instructions executed at a different privilege level, potentially resulting in privilege escalation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.307.1 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ip6t_eui64: reject invalid MAC header for all packets`eui64_mt6()` derives a modified EUI-64 from the Ethernet source addressand compares it with the low 64 bits of the IPv6 source address.The existing guard only rejects an invalid MAC header when`par->fragoff != 0`. For packets with `par->fragoff == 0`, `eui64_mt6()`can still reach `eth_hdr(skb)` even when the MAC header is not valid.Fix this by removing the `par->fragoff != 0` condition so that packetswith an invalid MAC header are rejected before accessing `eth_hdr(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.302.1).
-
Description: XZ Utils provide a general-purpose data-compression library plus command-line tools. Prior to version 5.8.3, if lzma_index_decoder() was used to decode an Index that contained no Records, the resulting lzma_index was left in a state where where a subsequent lzma_index_append() would allocate too little memory, and a buffer overflow would occur. This issue has been patched in version 5.8.3.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- liblzma5 > 0-0 (version in image is 5.0.5-6.7.1).
-
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.302.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 rsync 3.0.1 through 3.4.1, receive_xattr relies on an untrusted length value during a qsort call, leading to a receiver use-after-free. The victim must run rsync with -X (aka --xattrs). On Linux, many (but not all) common configurations are vulnerable. Non-Linux platforms are more widely vulnerable.
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.37.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.302.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.58.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv()l2cap_ecred_data_rcv() reads the SDU length field from skb->data usingget_unaligned_le16() without first verifying that skb contains at leastL2CAP_SDULEN_SIZE (2) bytes. When skb->len is less than 2, this readspast the valid data in the skb.The ERTM reassembly path correctly calls pskb_may_pull() before readingthe SDU length (l2cap_reassemble_sdu, L2CAP_SAR_START case). Apply thesame validation to the Enhanced Credit Based Flow Control data 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: ulpi: fix double free in ulpi_register_interface() error pathWhen device_register() fails, ulpi_register() calls put_device() onulpi->dev.The device release callback ulpi_dev_release() drops the OF nodereference and frees ulpi, but the current error path inulpi_register_interface() then calls kfree(ulpi) again, causing adouble free.Let put_device() handle the cleanup through ulpi_dev_release() andavoid freeing ulpi again in ulpi_register_interface().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: A flaw was found in gnutls. Servers configured with RSA-PSK (Rivest-Shamir-Adleman - Pre-Shared Key) wrongfully matched usernames containing a NUL character with truncated usernames. A remote attacker could exploit this by sending a specially crafted username, leading to an authentication bypass. This vulnerability allows an attacker to gain unauthorized access by circumventing the authentication process.
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:smb: client: fix in-place encryption corruption in SMB2_write()SMB2_write() places write payload in iov[1..n] as part of rq_iov.smb3_init_transform_rq() pointer-shares rq_iov, so crypt_message()encrypts iov[1] in-place, replacing the original plaintext withciphertext. On a replayable error, the retry sends the same iov[1]which now contains ciphertext instead of the original data,resulting in corruption.The corruption is most likely to be observed when connections areunstable, as reconnects trigger write retries that re-send thealready-encrypted data.This affects SFU mknod, MF symlinks, etc. On kernels before6.10 (prior to the netfs conversion), sync writes also usedthis path and were similarly affected. The async write pathwasn't unaffected as it uses rq_iter which gets deep-copied.Fix by moving the write payload into rq_iter via iov_iter_kvec(),so smb3_init_transform_rq() deep-copies it before encryption.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Completely fix fcport double freeIn qla24xx_els_dcmd_iocb() sp->free is set to qla2x00_els_dcmd_sp_free().When an error happens, this function is called by qla2x00_sp_release(),when kref_put() releases the first and the last reference.qla2x00_els_dcmd_sp_free() frees fcport by calling qla2x00_free_fcport().Doing it one more time after kref_put() is a bad idea.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: Mitgation of CVE-2026-4519 was incomplete. If the URL contained "%action" the mitigation could be bypassed for certain browser types the "webbrowser.open()" API could have commands injected into the underlying shell. See CVE-2026-4519 for details.
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.74.1).
-
Description: Python 2.7.14 is vulnerable to a Heap-Buffer-Overflow as well as a Heap-Use-After-Free. Python versions prior to 2.7.14 may also be vulnerable and it appears that Python 2.7.17 and prior may also be vulnerable however this has not been confirmed. The vulnerability lies when multiply threads are handling large amounts of data. In both cases there is essentially a race condition that occurs. For the Heap-Buffer-Overflow, Thread 2 is creating the size for a buffer, but Thread1 is already writing to the buffer without knowing how much to write. So when a large amount of data is being processed, it is very easy to cause memory corruption using a Heap-Buffer-Overflow. As for the Use-After-Free, Thread3->Malloc->Thread1->Free's->Thread2-Re-uses-Free'd Memory. The PSRT has stated that this is not a security vulnerability due to the fact that the attacker must be able to run code, however in some situations, such as function as a service, this vulnerability can potentially be used by an attacker to violate a trust boundary, as such the DWF feels this issue deserves a CVE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python3 > 0-0 (version in image is 3.4.10-25.180.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.51.3-9.47.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.302.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.302.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.302.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mISDN: annotate data-race around dev->workdev->work can re read locklessly in mISDN_read()and mISDN_poll(). Add READ_ONCE()/WRITE_ONCE() annotations.BUG: KCSAN: data-race in mISDN_ioctl / mISDN_readwrite to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1: misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline] mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583 __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583 x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fread to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0: mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112 do_loop_readv_writev fs/read_write.c:847 [inline] vfs_readv+0x3fb/0x690 fs/read_write.c:1020 do_readv+0xe7/0x210 fs/read_write.c:1080 __do_sys_readv fs/read_write.c:1165 [inline] __se_sys_readv fs/read_write.c:1162 [inline] __x64_sys_readv+0x45/0x50 fs/read_write.c:1162 x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fvalue changed: 0x00000000 -> 0x00000001
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/freeExynos Virtual Display driver performs memory alloc/free operationswithout lock protection, which easily causes concurrency problem.For example, use-after-free can occur in race scenario like this:``` CPU0 CPU1 CPU2 ---- ---- ---- vidi_connection_ioctl() if (vidi->connection) // true drm_edid = drm_edid_alloc(); // alloc drm_edid ... ctx->raw_edid = drm_edid; ... drm_mode_getconnector() drm_helper_probe_single_connector_modes() vidi_get_modes() if (ctx->raw_edid) // true drm_edid_dup(ctx->raw_edid); if (!drm_edid) // false ... vidi_connection_ioctl() if (vidi->connection) // false drm_edid_free(ctx->raw_edid); // free drm_edid ... drm_edid_alloc(drm_edid->edid) kmemdup(edid); // UAF!! ...```To prevent these vulns, at least in vidi_context, member variables relatedto memory alloc/free should be protected with ctx->lock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix use-after-free in nf_tables_addchain()nf_tables_addchain() publishes the chain to table->chains vialist_add_tail_rcu() (in nft_chain_add()) before registering hooks.If nf_tables_register_hook() then fails, the error path callsnft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy()with no RCU grace period in between.This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain.Add synchronize_rcu() between nft_chain_del() and the chain destroyso that all RCU readers -- both dump threads and in-flight packetevaluation -- have finished before the chain is 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Fix refcount bug and potential UAF in perf_mmapSyzkaller reported a refcount_t: addition on 0; use-after-free warningin perf_mmap.The issue is caused by a race condition between a failing mmap() setupand a concurrent mmap() on a dependent event (e.g., using outputredirection).In perf_mmap(), the ring_buffer (rb) is allocated and assigned toevent->rb with the mmap_mutex held. The mutex is then released toperform map_range().If map_range() fails, perf_mmap_close() is called to clean up.However, since the mutex was dropped, another thread attaching tothis event (via inherited events or output redirection) can acquirethe mutex, observe the valid event->rb pointer, and attempt toincrement its reference count. If the cleanup path has alreadydropped the reference count to zero, this results in ause-after-free or refcount saturation warning.Fix this by extending the scope of mmap_mutex to cover themap_range() call. This ensures that the ring buffer initializationand mapping (or cleanup on failure) happens atomically effectively,preventing other threads from accessing a half-initialized ordying ring 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: teql: Fix double-free in teql_master_xmitWhenever a TEQL devices has a lockless Qdisc as root, qdisc_reset shouldbe called using the seq_lock to avoid racing with the datapath. Failureto do so may cause crashes like the following:[ 238.028993][ T318] BUG: KASAN: double-free in skb_release_data (net/core/skbuff.c:1139)[ 238.029328][ T318] Free of addr ffff88810c67ec00 by task poc_teql_uaf_ke/318[ 238.029749][ T318][ 238.029900][ T318] CPU: 3 UID: 0 PID: 318 Comm: poc_teql_ke Not tainted 7.0.0-rc3-00149-ge5b31d988a41 #704 PREEMPT(full)[ 238.029906][ T318] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011[ 238.029910][ T318] Call Trace:[ 238.029913][ T318] [ 238.029916][ T318] dump_stack_lvl (lib/dump_stack.c:122)[ 238.029928][ T318] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)[ 238.029940][ T318] ? skb_release_data (net/core/skbuff.c:1139)[ 238.029944][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)...[ 238.029957][ T318] ? skb_release_data (net/core/skbuff.c:1139)[ 238.029969][ T318] kasan_report_invalid_free (mm/kasan/report.c:221 mm/kasan/report.c:563)[ 238.029979][ T318] ? skb_release_data (net/core/skbuff.c:1139)[ 238.029989][ T318] check_slab_allocation (mm/kasan/common.c:231)[ 238.029995][ T318] kmem_cache_free (mm/slub.c:2637 (discriminator 1) mm/slub.c:6168 (discriminator 1) mm/slub.c:6298 (discriminator 1))[ 238.030004][ T318] skb_release_data (net/core/skbuff.c:1139)...[ 238.030025][ T318] sk_skb_reason_drop (net/core/skbuff.c:1256)[ 238.030032][ T318] pfifo_fast_reset (./include/linux/ptr_ring.h:171 ./include/linux/ptr_ring.h:309 ./include/linux/skb_array.h:98 net/sched/sch_generic.c:827)[ 238.030039][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)...[ 238.030054][ T318] qdisc_reset (net/sched/sch_generic.c:1034)[ 238.030062][ T318] teql_destroy (./include/linux/spinlock.h:395 net/sched/sch_teql.c:157)[ 238.030071][ T318] __qdisc_destroy (./include/net/pkt_sched.h:328 net/sched/sch_generic.c:1077)[ 238.030077][ T318] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159)[ 238.030089][ T318] ? __pfx_qdisc_graft (net/sched/sch_api.c:1091)[ 238.030095][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 238.030102][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 238.030106][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 238.030114][ T318] tc_get_qdisc (net/sched/sch_api.c:1529 net/sched/sch_api.c:1556)...[ 238.072958][ T318] Allocated by task 303 on cpu 5 at 238.026275s:[ 238.073392][ T318] kasan_save_stack (mm/kasan/common.c:58)[ 238.073884][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5))[ 238.074230][ T318] __kasan_slab_alloc (mm/kasan/common.c:369)[ 238.074578][ T318] kmem_cache_alloc_node_noprof (./include/linux/kasan.h:253 mm/slub.c:4542 mm/slub.c:4869 mm/slub.c:4921)[ 238.076091][ T318] kmalloc_reserve (net/core/skbuff.c:616 (discriminator 107))[ 238.076450][ T318] __alloc_skb (net/core/skbuff.c:713)[ 238.076834][ T318] alloc_skb_with_frags (./include/linux/skbuff.h:1383 net/core/skbuff.c:6763)[ 238.077178][ T318] sock_alloc_send_pskb (net/core/sock.c:2997)[ 238.077520][ T318] packet_sendmsg (net/packet/af_packet.c:2926 net/packet/af_packet.c:3019 net/packet/af_packet.c:3108)[ 238.081469][ T318][ 238.081870][ T318] Freed by task 299 on cpu 1 at 238.028496s:[ 238.082761][ T318] kasan_save_stack (mm/kasan/common.c:58)[ 238.083481][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5))[ 238.085348][ T318] kasan_save_free_info (mm/kasan/generic.c:587 (discriminator 1))[ 238.085900][ T318] __kasan_slab_free (mm/---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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct()ctnetlink_dump_exp_ct() stores a conntrack pointer in cb->data for thenetlink dump callback ctnetlink_exp_ct_dump_table(), but drops theconntrack reference immediately after netlink_dump_start(). When thedump spans multiple rounds, the second recvmsg() triggers the dumpcallback which dereferences the now-freed conntrack via nfct_help(ct),leading to a use-after-free on ct->ext.The bug is that the netlink_dump_control has no .start or .donecallbacks to manage the conntrack reference across dump rounds. Otherdump functions in the same file (e.g. ctnetlink_get_conntrack) properlyuse .start/.done callbacks for this purpose.Fix this by adding .start and .done callbacks that hold and release theconntrack reference for the duration of the dump, and move thenfct_help() call after the cb->args[0] early-return check in the dumpcallback to avoid dereferencing ct->ext unnecessarily. BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0 Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133 CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY Call Trace: ctnetlink_exp_ct_dump_table+0x4f/0x2e0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 ? aa_sk_perm+0x184/0x450 sock_recvmsg+0xde/0xf0 Allocated by task 133: kmem_cache_alloc_noprof+0x134/0x440 __nf_conntrack_alloc+0xa8/0x2b0 ctnetlink_create_conntrack+0xa1/0x900 ctnetlink_new_conntrack+0x3cf/0x7d0 nfnetlink_rcv_msg+0x48e/0x510 netlink_rcv_skb+0xc9/0x1f0 nfnetlink_rcv+0xdb/0x220 netlink_unicast+0x3ec/0x590 netlink_sendmsg+0x397/0x690 __sys_sendmsg+0xf4/0x180 Freed by task 0: slab_free_after_rcu_debug+0xad/0x1e0 rcu_core+0x5c3/0x9c0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Hold net reference for the lifetime of /proc/fs/nfs/exports fdThe /proc/fs/nfs/exports proc entry is created at module initand persists for the module's lifetime. exports_proc_open()captures the caller's current network namespace and storesits svc_export_cache in seq->private, but takes no referenceon the namespace. If the namespace is subsequently torn down(e.g. container destruction after the opener does setns() to adifferent namespace), nfsd_net_exit() calls nfsd_export_shutdown()which frees the cache. Subsequent reads on the still-open fddereference the freed cache_detail, walking a freed hash table.Hold a reference on the struct net for the lifetime of the openfile descriptor. This prevents nfsd_net_exit() from running --and thus prevents nfsd_export_shutdown() from freeing the cache-- while any exports fd is open. cache_detail already storesits net pointer (cd->net, set by cache_create_net()), soexports_release() can retrieve it without additional per-filestorage.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_holdsco_recv_frame() reads conn->sk under sco_conn_lock() but immediatelyreleases the lock without holding a reference to the socket. A concurrentclose() can free the socket between the lock release and the subsequentsk->sk_state access, resulting in a use-after-free.Other functions in the same file (sco_sock_timeout(), sco_conn_del())correctly use sco_sock_hold() to safely hold a reference under the lock.Fix by using sco_sock_hold() to take a reference before releasing thelock, and adding sock_put() on all exit paths.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btintel: serialize btintel_hw_error() with hci_req_sync_lockbtintel_hw_error() issues two __hci_cmd_sync() calls (HCI_OP_RESETand Intel exception-info retrieval) without holdinghci_req_sync_lock(). This lets it race againsthci_dev_do_close() -> btintel_shutdown_combined(), which also runs__hci_cmd_sync() under the same lock. When both paths manipulatehdev->req_status/req_rsp concurrently, the close path may free theresponse skb first, and the still-running hw_error path hits aslab-use-after-free in kfree_skb().Wrap the whole recovery sequence in hci_req_sync_lock/unlock so itis serialized with every other synchronous HCI command issuer.Below is the data race report and the kasan report: BUG: data-race in __hci_cmd_sync_sk / btintel_shutdown_combined read of hdev->req_rsp at net/bluetooth/hci_sync.c:199 by task kworker/u17:1/83: __hci_cmd_sync_sk+0x12f2/0x1c30 net/bluetooth/hci_sync.c:200 __hci_cmd_sync+0x55/0x80 net/bluetooth/hci_sync.c:223 btintel_hw_error+0x114/0x670 drivers/bluetooth/btintel.c:254 hci_error_reset+0x348/0xa30 net/bluetooth/hci_core.c:1030 write/free by task ioctl/22580: btintel_shutdown_combined+0xd0/0x360 drivers/bluetooth/btintel.c:3648 hci_dev_close_sync+0x9ae/0x2c10 net/bluetooth/hci_sync.c:5246 hci_dev_do_close+0x232/0x460 net/bluetooth/hci_core.c:526 BUG: KASAN: slab-use-after-free in sk_skb_reason_drop+0x43/0x380 net/core/skbuff.c:1202 Read of size 4 at addr ffff888144a738dc by task kworker/u17:1/83: __hci_cmd_sync_sk+0x12f2/0x1c30 net/bluetooth/hci_sync.c:200 __hci_cmd_sync+0x55/0x80 net/bluetooth/hci_sync.c:223 btintel_hw_error+0x186/0x670 drivers/bluetooth/btintel.c:260
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix fanout UAF in packet_release() via NETDEV_UP race`packet_release()` has a race window where `NETDEV_UP` can re-register asocket into a fanout group's `arr[]` array. The re-registration is notcleaned up by `fanout_release()`, leaving a dangling pointer in the fanoutarray.`packet_release()` does NOT zero `po->num` in its `bind_lock` section.After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex`still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)`that already found the socket in `sklist` can re-register the hook.For fanout sockets, this re-registration calls `__fanout_link(sk, po)`which adds the socket back into `f->arr[]` and increments `f->num_members`,but does NOT increment `f->sk_ref`.The fix sets `po->num` to zero in `packet_release` while `bind_lock` isheld to prevent NETDEV_UP from linking, preventing the race window.This bug was found following an additional audit with Claude Code basedon CVE-2025-38617.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: make use of smbdirect_socket.recv_io.credits.availableThe logic off managing recv credits by counting posted recv_io andgranted credits is racy.That's because the peer might already consumed a credit,but between receiving the incoming recv at the hardwareand processing the completion in the 'recv_done' functionswe likely have a window where we grant credits, whichdon't really exist.So we better have a decicated counter for theavailable credits, which will be incrementedwhen we posted new recv buffers and drained whenwe grant the credits to the peer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: em28xx: fix use-after-free in em28xx_v4l2_open()em28xx_v4l2_open() reads dev->v4l2 without holding dev->lock,creating a race with em28xx_v4l2_init()'s error path andem28xx_v4l2_fini(), both of which free the em28xx_v4l2 structand set dev->v4l2 to NULL under dev->lock.This race leads to two issues: - use-after-free in v4l2_fh_init() when accessing vdev->ctrl_handler, since the video_device is embedded in the freed em28xx_v4l2 struct. - NULL pointer dereference in em28xx_resolution_set() when accessing v4l2->norm, since dev->v4l2 has been set to NULL.Fix this by moving the mutex_lock() before the dev->v4l2 read andadding a NULL check for dev->v4l2 under the lock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: blk-cgroup: fix use-after-free in cgwb_release_workfn()cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesseswb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the lastreference, the blkcg can be freed asynchronously (css_free_rwork_fn ->blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences thepointer to access blkcg->online_pin, resulting in a use-after-free: BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwb_release cgwb_release_workfn Call Trace: blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwb_release_workfn (mm/backing-dev.c:629) process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385) Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385)** Stack based on commit 66672af7a095 ("Add linux-next specific filesfor 20260410")I am seeing this crash sporadically in Meta fleet across multiple kernelversions. A full reproducer is available at:https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh(The race window is narrow. To make it easily reproducible, inject amsleep(100) between css_put() and blkcg_unpin_online() incgwb_release_workfn(). With that delay and a KASAN-enabled kernel, thereproducer triggers the splat reliably in less than a second.)Fix this by moving blkcg_unpin_online() before css_put(), so thecgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online()accesses 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Use scratch field in MMIO fragment to hold small write valuesWhen exiting to userspace to service an emulated MMIO write, copy theto-be-written value to a scratch field in the MMIO fragment if the sizeof the data payload is 8 bytes or less, i.e. can fit in a single chunk,instead of pointing the fragment directly at the source value.This fixes a class of use-after-free bugs that occur when the emulatorinitiates a write using an on-stack, local variable as the source, thewrite splits a page boundary, *and* both pages are MMIO pages. BecauseKVM's ABI only allows for physically contiguous MMIO requests, accessesthat split MMIO pages are separated into two fragments, and are sent touserspace one at a time. When KVM attempts to complete userspace MMIO inresponse to KVM_RUN after the first fragment, KVM will detect the secondfragment and generate a second userspace exit, and reference the on-stackvariable.The issue is most visible if the second KVM_RUN is performed by a separatetask, in which case the stack of the initiating task can show up as trulyfreed data. ================================================================== BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984 CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xbe/0xfd print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 check_memory_region+0xfd/0x1f0 memcpy+0x20/0x60 complete_emulated_mmio+0x305/0x420 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720 The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ==================================================================The bug can also be reproduced with a targeted KVM-Unit-Test by hackingKVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. byoverwrite the data value with garbage.Limit the use of the scratch fields to 8-byte or smaller accesses, and tojust writes, as larger accesses and reads are not affected thanks toimplementation details in the emulator, but add a sanity check to ensurethose details don't change in the future. Specifically, KVM never useson-stack variables for accesses larger that 8 bytes, e.g. uses an operandin the emulator context, and *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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failedWhen retrieving the PDH cert, don't attempt to copy the blobs to userspaceif the firmware command failed. If the failure was due to an invalidlength, i.e. the userspace buffer+length was too small, copying the numberof bytes _firmware_ requires will overflow the kernel-allocated buffer andleak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033 CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error codesays otherwise, as __sev_do_cmd_locked() is expected to return -EIO on anyfirwmware 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failedWhen retrieving the PEK CSR, don't attempt to copy the blob to userspaceif the firmware command failed. If the failure was due to an invalidlength, i.e. the userspace buffer+length was too small, copying the numberof bytes _firmware_ requires will overflow the kernel-allocated buffer andleak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405 CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error codesays otherwise, as __sev_do_cmd_locked() is expected to return -EIO on anyfirwmware 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd()In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr pointsdirectly into the mmap'd TX ring buffer shared with userspace. Thekernel validates the header via __packet_snd_vnet_parse() but thenre-reads all fields later in virtio_net_hdr_to_skb(). A concurrentuserspace thread can modify the vnet_hdr fields between validationand use, bypassing all safety checks.The non-TPACKET path (packet_snd()) already correctly copies vnet_hdrto a stack-local variable. All other vnet_hdr consumers in the kernel(tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TXpath is the only caller of virtio_net_hdr_to_skb() that reads directlyfrom user-controlled shared memory.Fix this by copying vnet_hdr from the mmap'd ring buffer to astack-local variable before validation and use, consistent with theapproach used in packet_snd() and all other 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: validate ND option lengths in vxlan_na_createvxlan_na_create() walks ND options according to option-providedlengths. A malformed option can make the parser advance beyond thecomputed option span or use a too-short source LLADDR option payload.Validate option lengths against the remaining NS option area beforeadvancing, and only read source LLADDR when the option is large enoughfor an Ethernet 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: ignore explicit helper on new expectationsUse the existing master conntrack helper, anything else is not reallysupported and it just makes validation more complicated, so just ignorewhat helper userspace suggests for this expectation.This was uncovered when validating CTA_EXPECT_CLASS via different helperprovided by userspace than the existing master conntrack helper: BUG: KASAN: slab-out-of-bounds in nf_ct_expect_related_report+0x2479/0x27c0 Read of size 4 at addr ffff8880043fe408 by task poc/102 Call Trace: nf_ct_expect_related_report+0x2479/0x27c0 ctnetlink_create_expect+0x22b/0x3b0 ctnetlink_new_expect+0x4bd/0x5c0 nfnetlink_rcv_msg+0x67a/0x950 netlink_rcv_skb+0x120/0x350Allowing to read kernel memory bytes off the expectation boundary.CTA_EXPECT_HELP_NAME is still used to offer the helper name to userspacevia netlink dump.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: lec: fix use-after-free in sock_def_readable()A race condition exists between lec_atm_close() setting priv->lecdto NULL and concurrent access to priv->lecd in send_to_lecd(),lec_handle_bridge(), and lec_atm_send(). When the socket is freedvia RCU while another thread is still using it, a use-after-freeoccurs in sock_def_readable() when accessing the socket's wait queue.The root cause is that lec_atm_close() clears priv->lecd withoutany synchronization, while callers dereference priv->lecd withoutany protection against concurrent teardown.Fix this by converting priv->lecd to an RCU-protected pointer:- Mark priv->lecd as __rcu in lec.h- Use rcu_assign_pointer() in lec_atm_close() and lecd_attach() for safe pointer assignment- Use rcu_access_pointer() for NULL checks that do not dereference the pointer in lec_start_xmit(), lec_push(), send_to_lecd() and lecd_attach()- Use rcu_read_lock/rcu_dereference/rcu_read_unlock in send_to_lecd(), lec_handle_bridge() and lec_atm_send() to safely access lecd- Use rcu_assign_pointer() followed by synchronize_rcu() in lec_atm_close() to ensure all readers have completed before proceeding. This is safe since lec_atm_close() is called from vcc_release() which holds lock_sock(), a sleeping lock.- Remove the manual sk_receive_queue drain from lec_atm_close() since vcc_destroy_socket() already drains it after lec_atm_close() returns.v2: Switch from spinlock + sock_hold/put approach to RCU to properly fix the race. The v1 spinlock approach had two issues pointed out by Eric Dumazet: 1. priv->lecd was still accessed directly after releasing the lock instead of using a local copy. 2. The spinlock did not prevent packets being queued after lec_atm_close() drains sk_receive_queue since timer and workqueue paths bypass netif_stop_queue().Note: Syzbot patch testing was attempted but the test VM terminated unexpectedly with "Connection to localhost closed by remote host", likely due to a QEMU AHCI emulation issue unrelated to this fix. Compile testing with "make W=1 net/atm/lec.o" passes cleanly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: algif_aead - Fix minimum RX size check for decryptionThe check for the minimum receive buffer size did not take thetag size into account during decryption. Fix this by adding therequired extra 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: roccat: fix use-after-free in roccat_report_eventroccat_report_event() iterates over the device->readers list withoutholding the readers_lock. This allows a concurrent roccat_release() toremove and free a reader while it's still being accessed, leading to ause-after-free.Protect the readers list traversal with the readers_lock 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: mixer: oss: Add card disconnect checkpointsALSA OSS mixer layer calls the kcontrol ops rather individually, andpending calls might be not always caught at disconnecting the device.For avoiding the potential UAF scenarios, add sanity checks of thecard disconnection at each entry point of OSS mixer accesses. Therwsem is taken just before that check, hence the rest context shouldbe covered by that 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: fix potential race in tcp_v6_syn_recv_sock()Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock()is done too late.After tcp_v4_syn_recv_sock(), the child socket is already visiblefrom TCP ehash table and other cpus might use it.Since newinet->pinet6 is still pointing to the listener ipv6_pinfobad things can happen as syzbot found.Move the problematic code in tcp_v6_mapped_child_init()and call this new helper from tcp_v4_syn_recv_sock() beforethe ehash insertion.This allows the removal of one tcp_sync_mss(), sincetcp_v4_syn_recv_sock() will call it with the correctcontext.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: fore200e: fix use-after-free in tasklets during device removalWhen the PCA-200E or SBA-200E adapter is being detached, the fore200eis deallocated. However, the tx_tasklet or rx_tasklet may still be runningor pending, leading to use-after-free bug when the already freed fore200eis accessed again in fore200e_tx_tasklet() or fore200e_rx_tasklet().One of the race conditions can occur as follows:CPU 0 (cleanup) | CPU 1 (tasklet)fore200e_pca_remove_one() | fore200e_interrupt() fore200e_shutdown() | tasklet_schedule() kfree(fore200e) | fore200e_tx_tasklet() | fore200e-> // UAFFix this by ensuring tx_tasklet or rx_tasklet is properly canceled beforethe fore200e is released. Add tasklet_kill() in fore200e_shutdown() tosynchronize with any pending or running tasklets. Moreover, sincefore200e_reset() could prevent further interrupts or data transfers,the tasklet_kill() should be placed after fore200e_reset() to preventthe tasklet from being rescheduled in fore200e_interrupt(). Finally,it only needs to do tasklet_kill() when the fore200e state is greaterthan or equal to FORE200E_STATE_IRQ, since tasklets are uninitializedin earlier states. In a word, the tasklet_kill() should be placed inthe FORE200E_STATE_IRQ branch within the switch...case structure.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix locking usage for tcon fieldsWe used to use the cifs_tcp_ses_lock to protect a lot of objectsthat are not just the server, ses or tcon lists. We later introducedsrv_lock, ses_lock and tc_lock to protect fields within thecorresponding structs. This was done to provide a more granularprotection and avoid unnecessary serialization.There were still a couple of uses of cifs_tcp_ses_lock to providetcon fields. In this patch, I've replaced them with tc_lock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: Fix net_device lifecycle with device_moveThe network device outlived its parent gadget device duringdisconnection, resulting in dangling sysfs links and null pointerdereference problems.A prior attempt to solve this by removing SET_NETDEV_DEV entirely [1]was reverted due to power management ordering concerns and a NO-CARRIERregression.A subsequent attempt to defer net_device allocation to bind [2] broke1:1 mapping between function instance and network device, making itimpossible for configfs to report the resolved interface name. Thisresults in a regression where the DHCP server fails on pmOS.Use device_move to reparent the net_device between the gadget device and/sys/devices/virtual/ across bind/unbind cycles. This preserves thenetwork interface across USB reconnection, allowing the DHCP server toretain their binding.Introduce gether_attach_gadget()/gether_detach_gadget() helpers and use__free(detach_gadget) macro to undo attachment on bind failure. Thebind_count ensures device_move executes only on the first bind.[1] https://lore.kernel.org/lkml/f2a4f9847617a0929d62025748384092e5f35cce.camel@crapouillou.net/[2] https://lore.kernel.org/linux-usb/795ea759-7eaf-4f78-81f4-01ffbf2d7961@ixit.cz/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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.68.1).
-
Description: When sed is invoked with both -i (in-place edit) and --follow-symlinks, the function open_next_file() performs two separate, non-atomic filesystem operations on the same path: 1. resolves symlink to its target and stores the resolved path for determining when output is written,2. opens the original symlink path (not the resolved one) to read the file. Between these two calls there is a race window. If an attacker atomically replaces the symlink with a different target during that window, sed will: read content from the new (attacker-chosen) symlink target and write the processed result to the path recorded in step 1. This can lead to arbitrary file overwrite with attacker-controlled content in the context of the sed process.This issue was fixed in version 4.10.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- sed > 0-0 (version in image is 4.2.2-7.6.1).
-
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.68.1).
- 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.68.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: prevent possible tunnel refcount underflowWhen a session is created, it sets a backpointer to its tunnel. Whenthe session refcount drops to 0, l2tp_session_free drops the tunnelrefcount if session->tunnel is non-NULL. However, session->tunnel isset in l2tp_session_create, before the tunnel refcount is incrementedby l2tp_session_register, which leaves a small window wheresession->tunnel is non-NULL when the tunnel refcount hasn't beenbumped.Moving the assignment to l2tp_session_register is trivial butl2tp_session_create calls l2tp_session_set_header_len which usessession->tunnel to get the tunnel's encap. Add an encap arg tol2tp_session_set_header_len to avoid using session->tunnel.If l2tpv3 sessions have colliding IDs, it is possible forl2tp_v3_session_get to race with l2tp_session_register and fetch asession which doesn't yet have session->tunnel set. Add a check forthis case.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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.74.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.24.1).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, a heap buffer over-read vulnerability exists in libpng's png_write_image_8bit function when processing 8-bit images through the simplified write API with convert_to_8bit enabled. The vulnerability affects 8-bit grayscale+alpha, RGB/RGBA, and images with incomplete row data. A conditional guard incorrectly allows 8-bit input to enter code expecting 16-bit input, causing reads up to 2 bytes beyond allocated buffer boundaries. This issue has been patched in version 1.6.51.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libpng16-16 > 0-0 (version in image is 1.6.8-15.24.1).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, an out-of-bounds read vulnerability exists in png_image_read_composite when processing palette images with PNG_FLAG_OPTIMIZE_ALPHA enabled. The palette compositing code in png_init_read_transformations incorrectly applies background compositing during premultiplication, violating the invariant component ≤ alpha x 257 required by the simplified PNG API. This issue has been patched in version 1.6.51.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libpng16-16 > 0-0 (version in image is 1.6.8-15.24.1).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, there is a heap buffer overflow vulnerability in the libpng simplified API function png_image_finish_read when processing 16-bit interlaced PNGs with 8-bit output format. Attacker-crafted interlaced PNG files cause heap writes beyond allocated buffer bounds. This issue has been patched in version 1.6.51.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libpng16-16 > 0-0 (version in image is 1.6.8-15.24.1).
-
Description: In Sudo through 1.8.29, an attacker with access to a Runas ALL sudoer account can impersonate a nonexistent user by invoking sudo with a numeric uid that is not associated with any user. NOTE: The software maintainer believes that this is not a vulnerability because running a command via sudo as a user not present in the local password database is an intentional feature. Because this behavior surprised some users, sudo 1.8.30 introduced an option to enable/disable this behavior with the default being disabled. However, this does not change the fact that sudo was behaving as intended, and as documented, in earlier versions
Packages affected:
- sles-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.302.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.302.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.302.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.302.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/rsrc: don't rely on user vaddr alignmentThere is no guaranteed alignment for user pointers, however thecalculation of an offset of the first page into a folio after coalescinguses some weird bit mask logic, get rid of 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.302.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRYfilemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY,as documented in mm/filemap.c: "If our return value has VM_FAULT_RETRY set, it's because the mmap_lock may be dropped before doing I/O or by lock_folio_maybe_drop_mmap()."When this happens, a concurrent munmap() can call remove_vma() and freethe vm_area_struct via RCU. The saved 'vma' pointer in ocfs2_fault() thenbecomes a dangling pointer, and the subsequent trace_ocfs2_fault() calldereferences it -- a use-after-free.Fix this by saving ip_blkno as a plain integer before callingfilemap_fault(), and removing vma from the trace event. Sinceip_blkno is copied by value before the lock can be dropped, itremains valid regardless of what happens to the vma or inodeafterward.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: s3c24xx: check the size of the SMBUS message before using itThe first byte of an i2c SMBUS message is the size, and it should beverified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAXbefore processing it.This is the same logic that was added in commit a6e04f05ce0b ("i2c:tegra: check msg length in SMBUS block read") to the i2c tegra 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: validate inline data i_size during inode readWhen reading an inode from disk, ocfs2_validate_inode_block() performsvarious sanity checks but does not validate the size of inline data. Ifthe filesystem is corrupted, an inode's i_size can exceed the actualinline data capacity (id_count).This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline databuffer, triggering a use-after-free when accessing directory entries fromfreed memory.In the syzbot report: - i_size was 1099511627576 bytes (~1TB) - Actual inline data capacity (id_count) is typically <256 bytes - A garbage rec_len (54648) caused ctx->pos to jump out of bounds - This triggered a UAF in ocfs2_check_dir_entry()Fix by adding a validation check in ocfs2_validate_inode_block() to ensureinodes with inline data have i_size <= id_count. This catches thecorruption early during inode read and prevents all downstream code fromoperating on invalid 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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.19.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: Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- vim > 0-0 (version in image is 9.2.0280-17.62.1).
-
Description: Vim is an open source, command line text editor. Prior to 9.2.0357, A command injection vulnerability exists in Vim's tag file processing. When resolving a tag, the filename field from the tags file is passed through wildcard expansion to resolve environment variables and wildcards. If the filename field contains backtick syntax (e.g., `command`), Vim executes the embedded command via the system shell with the full privileges of the running user.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- vim > 0-0 (version in image is 9.2.0280-17.62.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix transaction abort on set received ioctl due to item overflowIf the set received ioctl fails due to an item overflow when attempting toadd the BTRFS_UUID_KEY_RECEIVED_SUBVOL we have to abort the transactionsince we did some metadata updates before.This means that if a user calls this ioctl with the same received UUIDfield for a lot of subvolumes, we will hit the overflow, trigger thetransaction abort and turn the filesystem into RO mode. A malicious usercould exploit this, and this ioctl does not even requires that a userhas admin privileges (CAP_SYS_ADMIN), only that he/she owns the subvolume.Fix this by doing an early check for item overflow before starting atransaction. This is also race safe because we are holding the subvol_semsemaphore in exclusive (write) mode.A test case for fstests will follow soon.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: Vim is an open source, command line text editor. Prior to version 9.2.0450, a heap buffer overflow exists in read_compound() in src/spellfile.c when loading a crafted spell file (.spl) with UTF-8 encoding active. An attacker-controlled length field in the spell file's compound section overflows a 32-bit signed integer multiplication, causing a small buffer to be allocated for a write loop that runs many iterations, overflowing the heap. Because the 'spelllang' option can be set from a modeline, a text file modeline can trigger spell file loading if a malicious .spl file has been planted on the runtimepath. This issue has been patched in version 9.2.0450.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- vim > 0-0 (version in image is 9.2.0280-17.62.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.51.3-9.47.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.21.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.302.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.302.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.302.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.180.1).
-
Description: A vulnerability was recently discovered in the rpc.mountd daemon in the nfs-utils package for Linux, that allows a NFSv3 client to escalate theprivileges assigned to it in the /etc/exports file at mount time. In particular, it allows the client to access any subdirectory or subtree of an exported directory, regardless of the set file permissions, and regardless of any 'root_squash' or 'all_squash' attributes that would normally be expected to apply to that client.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- nfs-client > 0-0 (version in image is 1.3.0-34.53.5).
-
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.74.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: 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.39.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.39.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix bsg_done() causing double freeKernel panic observed on system,[5353358.825191] BUG: unable to handle page fault for address: ff5f5e897b024000[5353358.825194] #PF: supervisor write access in kernel mode[5353358.825195] #PF: error_code(0x0002) - not-present page[5353358.825196] PGD 100006067 P4D 0[5353358.825198] Oops: 0002 [#1] PREEMPT SMP NOPTI[5353358.825200] CPU: 5 PID: 2132085 Comm: qlafwupdate.sub Kdump: loaded Tainted: G W L ------- --- 5.14.0-503.34.1.el9_5.x86_64 #1[5353358.825203] Hardware name: HPE ProLiant DL360 Gen11/ProLiant DL360 Gen11, BIOS 2.44 01/17/2025[5353358.825204] RIP: 0010:memcpy_erms+0x6/0x10[5353358.825211] RSP: 0018:ff591da8f4f6b710 EFLAGS: 00010246[5353358.825212] RAX: ff5f5e897b024000 RBX: 0000000000007090 RCX: 0000000000001000[5353358.825213] RDX: 0000000000001000 RSI: ff591da8f4fed090 RDI: ff5f5e897b024000[5353358.825214] RBP: 0000000000010000 R08: ff5f5e897b024000 R09: 0000000000000000[5353358.825215] R10: ff46cf8c40517000 R11: 0000000000000001 R12: 0000000000008090[5353358.825216] R13: ff591da8f4f6b720 R14: 0000000000001000 R15: 0000000000000000[5353358.825218] FS: 00007f1e88d47740(0000) GS:ff46cf935f940000(0000) knlGS:0000000000000000[5353358.825219] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[5353358.825220] CR2: ff5f5e897b024000 CR3: 0000000231532004 CR4: 0000000000771ef0[5353358.825221] PKRU: 55555554[5353358.825222] Call Trace:[5353358.825223] [5353358.825224] ? show_trace_log_lvl+0x1c4/0x2df[5353358.825229] ? show_trace_log_lvl+0x1c4/0x2df[5353358.825232] ? sg_copy_buffer+0xc8/0x110[5353358.825236] ? __die_body.cold+0x8/0xd[5353358.825238] ? page_fault_oops+0x134/0x170[5353358.825242] ? kernelmode_fixup_or_oops+0x84/0x110[5353358.825244] ? exc_page_fault+0xa8/0x150[5353358.825247] ? asm_exc_page_fault+0x22/0x30[5353358.825252] ? memcpy_erms+0x6/0x10[5353358.825253] sg_copy_buffer+0xc8/0x110[5353358.825259] qla2x00_process_vendor_specific+0x652/0x1320 [qla2xxx][5353358.825317] qla24xx_bsg_request+0x1b2/0x2d0 [qla2xxx]Most routines in qla_bsg.c call bsg_done() only for success cases.However a few invoke it for failure case as well leading to a doublefree. Validate before calling bsg_done().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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.74.1).
-
Description: A flaw was found in libssh. The API function `ssh_get_hexa()` is vulnerable to a denial of service when processing zero-length input. This can be exploited remotely by an attacker during GSSAPI (Generic Security Service Application Program Interface) authentication if the server's logging verbosity is set to `SSH_LOG_PACKET (3)` or higher. Successful exploitation could lead to a self-Denial of Service of the per-connection daemon process.
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.21.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: add xmit recursion limit to tunnel xmit functionsTunnel xmit functions (iptunnel_xmit, ip6tunnel_xmit) lack their ownrecursion limit. When a bond device in broadcast mode has GRE tapinterfaces as slaves, and those GRE tunnels route back through thebond, multicast/broadcast traffic triggers infinite recursion betweenbond_xmit_broadcast() and ip_tunnel_xmit()/ip6_tnl_xmit(), causingkernel stack overflow.The existing XMIT_RECURSION_LIMIT (8) in the no-qdisc path is notsufficient because tunnel recursion involves route lookups and full IPoutput, consuming much more stack per level. Use a lower limit of 4(IP_TUNNEL_RECURSION_LIMIT) to prevent overflow.Add recursion detection using dev_xmit_recursion helpers directly iniptunnel_xmit() and ip6tunnel_xmit() to cover all IPv4/IPv6 tunnelpaths including UDP encapsulated tunnels (VXLAN, Geneve, etc.).Move dev_xmit_recursion helpers from net/core/dev.h to public headerinclude/linux/netdevice.h so they can be used by tunnel code. BUG: KASAN: stack-out-of-bounds in blake2s.constprop.0+0xe7/0x160 Write of size 32 at addr ffff88810033fed0 by task kworker/0:1/11 Workqueue: mld mld_ifc_work Call Trace: __build_flow_key.constprop.0 (net/ipv4/route.c:515) ip_rt_update_pmtu (net/ipv4/route.c:1073) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:84) ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) gre_tap_xmit (net/ipv4/ip_gre.c:779) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279) bond_start_xmit (drivers/net/bonding/bond_main.c:5530) dev_hard_start_xmit (net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:4841) ip_finish_output2 (net/ipv4/ip_output.c:237) ip_output (net/ipv4/ip_output.c:438) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86) gre_tap_xmit (net/ipv4/ip_gre.c:779) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279) bond_start_xmit (drivers/net/bonding/bond_main.c:5530) dev_hard_start_xmit (net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:4841) ip_finish_output2 (net/ipv4/ip_output.c:237) ip_output (net/ipv4/ip_output.c:438) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86) ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) gre_tap_xmit (net/ipv4/ip_gre.c:779) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279) bond_start_xmit (drivers/net/bonding/bond_main.c:5530) dev_hard_start_xmit (net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:4841) mld_sendpack mld_ifc_work process_one_work worker_thread
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix NULL pointer dereference in mesh_rx_csa_frame()In mesh_rx_csa_frame(), elems->mesh_chansw_params_ie is dereferencedat lines 1638 and 1642 without a prior NULL check: ifmsh->chsw_ttl = elems->mesh_chansw_params_ie->mesh_ttl; ... pre_value = le16_to_cpu(elems->mesh_chansw_params_ie->mesh_pre_value);The mesh_matches_local() check above only validates the Mesh ID,Mesh Configuration, and Supported Rates IEs. It does not verify thepresence of the Mesh Channel Switch Parameters IE (element ID 118).When a received CSA action frame omits that IE, ieee802_11_parse_elems()leaves elems->mesh_chansw_params_ie as NULL, and the unconditionaldereference causes a kernel NULL pointer dereference.A remote mesh peer with an established peer link (PLINK_ESTAB) cantrigger this by sending a crafted SPECTRUM_MGMT/CHL_SWITCH action framethat includes a matching Mesh ID and Mesh Configuration IE but omits theMesh Channel Switch Parameters IE. No authentication beyond the defaultopen mesh peering is required.Crash confirmed on kernel 6.17.0-5-generic via mac80211_hwsim: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:ieee80211_mesh_rx_queued_mgmt+0x143/0x2a0 [mac80211] CR2: 0000000000000000Fix by adding a NULL check for mesh_chansw_params_ie aftermesh_matches_local() returns, consistent with how other optional IEsare guarded throughout the mesh code.The bug has been present since v3.13 (released 2014-01-19).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix NULL deref in mesh_matches_local()mesh_matches_local() unconditionally dereferences ie->mesh_config tocompare mesh configuration parameters. When called frommesh_rx_csa_frame(), the parsed action-frame elements may not contain aMesh Configuration IE, leaving ie->mesh_config NULL and triggering akernel NULL pointer dereference.The other two callers are already safe: - ieee80211_mesh_rx_bcn_presp() checks !elems->mesh_config before calling mesh_matches_local() - mesh_plink_get_event() is only reached through mesh_process_plink_frame(), which checks !elems->mesh_config, toomesh_rx_csa_frame() is the only caller that passes raw parsed elementsto mesh_matches_local() without guarding mesh_config. An adjacentattacker can exploit this by sending a crafted CSA action frame thatincludes a valid Mesh ID IE but omits the Mesh Configuration IE,crashing the kernel.The captured crash log:Oops: general protection fault, probably for non-canonical address ...KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]Workqueue: events_unbound cfg80211_wiphy_work[...]Call Trace: ? __pfx_mesh_matches_local (net/mac80211/mesh.c:65) ieee80211_mesh_rx_queued_mgmt (net/mac80211/mesh.c:1686) [...] ieee80211_iface_work (net/mac80211/iface.c:1754 net/mac80211/iface.c:1802) [...] cfg80211_wiphy_work (net/wireless/core.c:426) process_one_work (net/kernel/workqueue.c:3280) ? assign_work (net/kernel/workqueue.c:1219) worker_thread (net/kernel/workqueue.c:3352) ? __pfx_worker_thread (net/kernel/workqueue.c:3385) kthread (net/kernel/kthread.c:436) [...] ret_from_fork_asm (net/arch/x86/entry/entry_64.S:255) This patch adds a NULL check for ie->mesh_config at the top ofmesh_matches_local() to return false early when the Mesh ConfigurationIE is absent.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: add NULL checks for idev in SRv6 paths__in6_dev_get() can return NULL when the device has no IPv6 configuration(e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER).Add NULL checks for idev returned by __in6_dev_get() in bothseg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULLpointer dereferences.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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.39.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.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loopl2cap_config_req() processes CONFIG_REQ for channels in BT_CONNECTEDstate to support L2CAP reconfiguration (e.g. MTU changes). However,since both CONF_INPUT_DONE and CONF_OUTPUT_DONE are already set fromthe initial configuration, the reconfiguration path falls through tol2cap_ertm_init(), which re-initializes tx_q, srej_q, srej_list, andretrans_list without freeing the previous allocations and setschan->sdu to NULL without freeing the existing skb. This leaks allpreviously allocated ERTM resources.Additionally, l2cap_parse_conf_req() does not validate the minimumvalue of remote_mps derived from the RFC max_pdu_size option. A zerovalue propagates to l2cap_segment_sdu() where pdu_len becomes zero,causing the while loop to never terminate since len is neverdecremented, exhausting all available memory.Fix the double-init by skipping l2cap_ertm_init() andl2cap_chan_ready() when the channel is already in BT_CONNECTED state,while still allowing the reconfiguration parameters to be updatedthrough l2cap_parse_conf_req(). Also add a pdu_len zero check inl2cap_segment_sdu() as a safeguard.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbip: validate number_of_packets in usbip_pack_ret_submit()When a USB/IP client receives a RET_SUBMIT response,usbip_pack_ret_submit() unconditionally overwritesurb->number_of_packets from the network PDU. This value issubsequently used as the loop bound in usbip_recv_iso() andusbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexiblearray whose size was fixed at URB allocation time based on the*original* number_of_packets from the CMD_SUBMIT.A malicious USB/IP server can set number_of_packets in the responseto a value larger than what was originally submitted, causing a heapout-of-bounds write when usbip_recv_iso() writes tourb->iso_frame_desc[i] beyond the allocated region.KASAN confirmed this with kernel 7.0.0-rc5: BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69 The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40)The server side (stub_rx.c) and gadget side (vudc_rx.c) alreadyvalidate number_of_packets in the CMD_SUBMIT path since commitsc6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handlemalicious input") and b78d830f0049 ("usbip: fix vudc_rx: hardenCMD_SUBMIT path to handle malicious input"). The server side validatesagainst USBIP_MAX_ISO_PACKETS because no URB exists yet at that point.On the client side we have the original URB, so we can use the tighterbound: the response must not exceed the original number_of_packets.This mirrors the existing validation of actual_length againsttransfer_buffer_length in usbip_recv_xbuff(), which checks theresponse value against the original allocation size.Kelvin Mbogo's series ("usb: usbip: fix integer overflow inusbip_recv_iso()", v2) hardens the receive-side functions themselves;this patch complements that work by catching the bad value at itssource -- in usbip_pack_ret_submit() before the overwrite -- andusing the tighter per-URB allocation bound rather than the globalUSBIP_MAX_ISO_PACKETS limit.Fix this by checking rpdu->number_of_packets againsturb->number_of_packets in usbip_pack_ret_submit() before theoverwrite. On violation, clamp to zero so that usbip_recv_iso() andusbip_pad_iso() safely return early.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: reject oversized global TT response buffersbatadv_tt_prepare_tvlv_global_data() builds the allocation length for aglobal TT response in 16-bit temporaries. When a remote originatoradvertises a large enough global TT, the TT payload length plus the VLANheader offset can exceed 65535 and wrap before kmalloc().The full-table response path still uses the original TT payload length whenit fills tt_change, so the wrapped allocation is too small andbatadv_tt_prepare_tvlv_global_data() writes past the end of the heap objectbefore the later packet-size check runs.Fix this by rejecting TT responses whose TVLV value length cannot fit inthe 16-bit TVLV payload length field.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: Vulnerability in the OpenSSH GSSAPI delta included in various Linux distributions. This vulnerability affects the GSSAPI patches added by various Linux distributions and does not affect the OpenSSH upstream project itself. The usage of sshpkt_disconnect() on an error, which does not terminate the process, allows an attacker to send an unexpected GSSAPI message type during the GSSAPI key exchange to the server, which will call the underlying function and continue the execution of the program without setting the related connection variables. As the variables are not initialized to NULL the code later accesses those uninitialized variables, accessing random memory, which could lead to undefined behavior. The recommended workaround is to use ssh_packet_disconnect() instead, which does terminate the process. The impact of the vulnerability depends heavily on the compiler flag hardening configuration.
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.34.1).
-
Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.16 and prior, the RSS notifier allows .. path traversal in notify-recipient-uri (e.g., rss:///../job.cache), letting a remote IPP client write RSS XML bytes outside CacheDir/rss (anywhere that is lp-writable). In particular, because CacheDir is group-writable by default (typically root:lp and mode 0770), the notifier (running as lp) can replace root-managed state files via temp-file + rename(). This PoC clobbers CacheDir/job.cache with RSS XML, and after restarting cupsd the scheduler fails to parse the job cache and previously queued jobs disappear. At time of publication, there are no publicly available patches.
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.62.1).
-
Description: A flaw was found in gnutls. This vulnerability occurs because gnutls performs case-sensitive comparisons of `nameConstraints` labels, specifically for `dNSName` (DNS) or `rfc822Name` (email) constraints within `excludedSubtrees` or `permittedSubtrees`. A remote attacker can exploit this by crafting a leaf certificate with casing differences in the Subject Alternative Name (SAN), leading to a policy bypass where a certificate that should be rejected is instead accepted. This could result in unauthorized access or information disclosure.
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: Unknown.
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: libcurl might in some circumstances reuse the wrong connection when asked todo an authenticated HTTP(S) request after a Negotiate-authenticated one, whenboth use the same host.libcurl features a pool of recent connections so that subsequent requests canreuse an existing connection to avoid overhead.When reusing a connection a range of criteria must be met. Due to a logicalerror in the code, a request that was issued by an application couldwrongfully reuse an existing connection to the same server that wasauthenticated using different credentials.An application that first uses Negotiate authentication to a server with`user1:password1` and then does another operation to the same server askingfor any authentication method but for `user2:password2` (while the previousconnection is still alive) - the second request gets confused and wronglyreuses the same connection and sends the new request over that connectionthinking it uses a mix of user1's and user2's credentials when it is in factstill using the connection authenticated for user1...
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.120.1).
-
Description: A flaw was found in libxml2. This vulnerability occurs when the library processes a specially crafted XML Schema Definition (XSD) validated document that includes an internal entity reference. An attacker could exploit this by providing a malicious document, leading to a type confusion error that causes the application to crash. This results in a denial of service (DoS), making the affected system or application unavailable.
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.99.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless qdiscsWhen shrinking the number of real tx queues,netif_set_real_num_tx_queues() calls qdisc_reset_all_tx_gt() to flushqdiscs for queues which will no longer be used.qdisc_reset_all_tx_gt() currently serializes qdisc_reset() withqdisc_lock(). However, for lockless qdiscs, the dequeue path isserialized by qdisc_run_begin/end() using qdisc->seqlock instead, soqdisc_reset() can run concurrently with __qdisc_run() and free skbswhile they are still being dequeued, leading to UAF.This can easily be reproduced on e.g. virtio-net by imposing heavytraffic while frequently changing the number of queue pairs: iperf3 -ub0 -c $peer -t 0 & while :; do ethtool -L eth0 combined 1 ethtool -L eth0 combined 2 doneWith KASAN enabled, this leads to reports like: BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760 ... Call Trace: ... __qdisc_run+0x133f/0x1760 __dev_queue_xmit+0x248f/0x3550 ip_finish_output2+0xa42/0x2110 ip_output+0x1a7/0x410 ip_send_skb+0x2e6/0x480 udp_send_skb+0xb0a/0x1590 udp_sendmsg+0x13c9/0x1fc0 ... Allocated by task 1270 on cpu 5 at 44.558414s: ... alloc_skb_with_frags+0x84/0x7c0 sock_alloc_send_pskb+0x69a/0x830 __ip_append_data+0x1b86/0x48c0 ip_make_skb+0x1e8/0x2b0 udp_sendmsg+0x13a6/0x1fc0 ... Freed by task 1306 on cpu 3 at 44.558445s: ... kmem_cache_free+0x117/0x5e0 pfifo_fast_reset+0x14d/0x580 qdisc_reset+0x9e/0x5f0 netif_set_real_num_tx_queues+0x303/0x840 virtnet_set_channels+0x1bf/0x260 [virtio_net] ethnl_set_channels+0x684/0xae0 ethnl_default_set_doit+0x31a/0x890 ...Serialize qdisc_reset_all_tx_gt() against the lockless dequeue path bytaking qdisc->seqlock for TCQ_F_NOLOCK qdiscs, matching theserialization model already used by dev_reset_queue().Additionally clear QDISC_STATE_NON_EMPTY after reset so the qdisc statereflects an empty queue, avoiding needless re-scheduling.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mana: fix use-after-free in mana_hwc_destroy_channel() by reordering teardownA potential race condition exists in mana_hwc_destroy_channel() wherehwc->caller_ctx is freed before the HWC's Completion Queue (CQ) andEvent Queue (EQ) are destroyed. This allows an in-flight CQ interrupthandler to dereference freed memory, leading to a use-after-free orNULL pointer dereference in mana_hwc_handle_resp().mana_smc_teardown_hwc() signals the hardware to stop but does notsynchronize against IRQ handlers already executing on other CPUs. TheIRQ synchronization only happens in mana_hwc_destroy_cq() viamana_gd_destroy_eq() -> mana_gd_deregister_irq(). Since this runsafter kfree(hwc->caller_ctx), a concurrent mana_hwc_rx_event_handler()can dereference freed caller_ctx (and rxq->msg_buf) inmana_hwc_handle_resp().Fix this by reordering teardown to reverse-of-creation order: destroythe TX/RX work queues and CQ/EQ before freeing hwc->caller_ctx. Thisensures all in-flight interrupt handlers complete before the memory theyaccess is 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:team: fix header_ops type confusion with non-Ethernet portsSimilar to commit 950803f72547 ("bonding: fix type confusion inbond_setup_by_slave()") team has the same class of header_ops typeconfusion.For non-Ethernet ports, team_setup_by_port() copies port_dev->header_opsdirectly. When the team device later calls dev_hard_header() ordev_parse_header(), these callbacks can run with the team net_deviceinstead of the real lower device, so netdev_priv(dev) is interpreted asthe wrong private type and can crash.The syzbot report shows a crash in bond_header_create(), but the rootcause is in team: the topology is gre -> bond -> team, and team callsthe inherited header_ops with its own net_device instead of the lowerdevice, so bond_header_create() receives a team device and interpretsnetdev_priv() as bonding private data, causing a type confusion crash.Fix this by introducing team header_ops wrappers for create/parse,selecting a team port under RCU, and calling the lower device callbackswith port->dev, so each callback always sees the correct net_devicecontext.Also pass the selected lower device to the lower parse callback, sorecursion is bounded in stacked non-Ethernet topologies and parsecallbacks always run with the correct device 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: prevent policy_hthresh.work from racing with netns teardownA XFRM_MSG_NEWSPDINFO request can queue the per-net work itempolicy_hthresh.work onto the system workqueue.The queued callback, xfrm_hash_rebuild(), retrieves the enclosingstruct net via container_of(). If the net namespace is torn downbefore that work runs, the associated struct net may already havebeen freed, and xfrm_hash_rebuild() may then dereference stale memory.xfrm_policy_fini() already flushes policy_hash_work during teardown,but it does not synchronize policy_hthresh.work.Synchronize policy_hthresh.work in xfrm_policy_fini() as well, so thequeued work cannot outlive the net namespace teardown and access afreed struct 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:driver core: platform: use generic driver_override infrastructureWhen a driver is probed through __driver_attach(), the bus' match()callback is called without the device lock held, thus accessing thedriver_override field without a lock, which can cause a UAF.Fix this by using the driver-core driver_override infrastructure takingcare of proper locking internally.Note that calling match() from __driver_attach() without the device lockheld is intentional. [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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: raw: fix ro->uniq use-after-free in raw_rcv()raw_release() unregisters raw CAN receive filters via can_rx_unregister(),but receiver deletion is deferred with call_rcu(). This leaves a windowwhere raw_rcv() may still be running in an RCU read-side critical sectionafter raw_release() frees ro->uniq, leading to a use-after-free of thepercpu uniq storage.Move free_percpu(ro->uniq) out of raw_release() and into a raw-specificsocket destructor. can_rx_unregister() takes an extra reference to thesocket and only drops it from the RCU callback, so freeing uniq fromsk_destruct ensures the percpu area is not released until the relevantcallbacks have drained.[mkl: applied manually]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: 6fire: fix use-after-free on disconnectIn usb6fire_chip_abort(), the chip struct is allocated as the card'sprivate data (via snd_card_new with sizeof(struct sfire_chip)). Whensnd_card_free_when_closed() is called and no file handles are open, thecard and embedded chip are freed synchronously. The subsequentchip->card = NULL write then hits freed slab memory.Call trace: usb6fire_chip_abort sound/usb/6fire/chip.c:59 [inline] usb6fire_chip_disconnect+0x348/0x358 sound/usb/6fire/chip.c:182 usb_unbind_interface+0x1a8/0x88c drivers/usb/core/driver.c:458 ... hub_event+0x1a04/0x4518 drivers/usb/core/hub.c:5953Fix by moving the card lifecycle out of usb6fire_chip_abort() and intousb6fire_chip_disconnect(). The card pointer is saved in a localbefore any teardown, snd_card_disconnect() is called first to preventnew opens, URBs are aborted while chip is still valid, andsnd_card_free_when_closed() is called last so chip is never accessedafter the card may be 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: hold claim backbone gateways by referencebatadv_bla_add_claim() can replace claim->backbone_gw and drop the oldgateway's last reference while readers still follow the pointer.The netlink claim dump path dereferences claim->backbone_gw->orig andtakes claim->backbone_gw->crc_lock without pinning the underlyingbackbone gateway. batadv_bla_check_claim() still has the same nakedpointer access pattern.Reuse batadv_bla_claim_get_backbone_gw() in both readers so they operateon a stable gateway reference until the read-side work is complete.This keeps the dump and claim-check paths aligned with the lifetimerules introduced for the other BLA claim 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: hold dev ref until after transport_finish NF_HOOKAfter async crypto completes, xfrm_input_resume() calls dev_put()immediately on re-entry before the skb reaches transport_finish.The skb->dev pointer is then used inside NF_HOOK and its okfn,which can race with device teardown.Remove the dev_put from the async resumption entry and insteaddrop the reference after the NF_HOOK call in transport_finish,using a saved device pointer since NF_HOOK may consume the skb.This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skipthe okfn.For non-transport exits (decaps, gro, drop) and secondaryasync return points, release the reference inline whenasync is 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:openvswitch: defer tunnel netdev_put to RCU releaseovs_netdev_tunnel_destroy() may run after NETDEV_UNREGISTER alreadydetached the device. Dropping the netdev reference in destroy can racewith concurrent readers that still observe vport->dev.Do not release vport->dev in ovs_netdev_tunnel_destroy(). Instead, letvport_netdev_free() drop the reference from the RCU callback, matchingthe non-tunnel destroy path and avoiding additional synchronizationunder RTNL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:driver core: enforce device_lock for driver_match_device()Currently, driver_match_device() is called from three sites. One site(__device_attach_driver) holds device_lock(dev), but the other two(bind_store and __driver_attach) do not. This inconsistency means thatbus match() callbacks are not guaranteed to be called with the lockheld.Fix this by introducing driver_match_device_locked(), which guaranteesholding the device lock using a scoped guard. Replace the unlocked callsin bind_store() and __driver_attach() with this new helper. Also add alock assertion to driver_match_device() to enforce this guarantee.This consistency also fixes a known race condition. The driver_overrideimplementation relies on the device_lock, so the missing lock led to theuse-after-free (UAF) reported in Bugzilla for buses using this field.Stress testing the two newly locked paths for 24 hours withCONFIG_PROVE_LOCKING and CONFIG_LOCKDEP enabled showed no UAF recurrenceand no lockdep warnings.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: gyro: mpu3050: Move iio_device_register() to correct locationiio_device_register() should be at the end of the probe function toprevent race conditions.Place iio_device_register() at the end of the probe function and placeiio_device_unregister() accordingly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: gyro: mpu3050: Fix incorrect free_irq() variableThe handler for the IRQ part of this driver is mpu3050->trig but,in the teardown free_irq() is called with handler mpu3050.Use correct IRQ handler when calling free_irq().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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.302.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.302.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.302.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.302.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.302.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.120.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: libertas: fix use-after-free in lbs_free_adapter()The lbs_free_adapter() function uses timer_delete() (non-synchronous)for both command_timer and tx_lockup_timer before the structure isfreed. This is incorrect because timer_delete() does not wait forany running timer callback to complete.If a timer callback is executing when lbs_free_adapter() is called,the callback will access freed memory since lbs_cfg_free() frees thecontaining structure immediately after lbs_free_adapter() returns.Both timer callbacks (lbs_cmd_timeout_handler and lbs_tx_lockup_handler)access priv->driver_lock, priv->cur_cmd, priv->dev, and other fields,which would all be use-after-free violations.Use timer_delete_sync() instead to ensure any running timer callbackhas completed before returning.This bug was introduced in commit 8f641d93c38a ("libertas: detect TXlockups and reset hardware") where del_timer() was used instead ofdel_timer_sync() in the cleanup path. The command_timer has had thesame issue since the driver was first written.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drbd: fix "LOGIC BUG" in drbd_al_begin_io_nonblock()Even though we check that we "should" be able to do lc_get_cumulative()while holding the device->al_lock spinlock, it may still fail,if some other code path decided to do lc_try_lock() with bad timing.If that happened, we logged "LOGIC BUG for enr=...",but still did not return an error.The rest of the code now assumed that this request has referencesfor the relevant activity log extents.The implcations are that during an active resync, mutual exclusivity ofresync versus application IO is not guaranteed. And a potential crashat this point may not realizs that these extents could have been targetof in-flight IO and would need to be resynced just in case.Also, once the request completes, it will give up activity log references itdoes not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put().Fix:Do not crash the kernel for a condition that is harmless during normaloperation: also catch "e->refcnt == 0", not only "e == NULL"when being noisy about "al_complete_io() called on inactive extent %u\n".And do not try to be smart and "guess" whether something will work, thenbe surprised when it does not.Deal with the fact that it may or may not work. If it does not, remember apossible "partially in activity log" state (only possible for requests thatcross extent boundaries), and return an error code fromdrbd_al_begin_io_nonblock().A latter call for the same request will then resume from where we left off.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: radiotap: reject radiotap with unknown bitsThe radiotap parser is currently only used with the radiotapnamespace (not with vendor namespaces), but if the undefinedfield 18 is used, the alignment/size is unknown as well. Inthis case, iterator->_next_ns_data isn't initialized (it'sonly set for skipping vendor namespaces), and syzbot pointsout that we later compare against this uninitialized value.Fix this by moving the rejection of unknown radiotap fieldsdown to after the in-namespace lookup, so it will really useiterator->_next_ns_data only for vendor namespaces, even incase undefined fields are 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_ife: Fix metalist update behaviorWhenever an ife action replace changes the metalist, instead ofreplacing the old data on the metalist, the current ife code is appendingthe new metadata. Aside from being innapropriate behavior, this may leadto an unbounded addition of metadata to the metalist which might cause anout of bounds error when running the encode op:[ 138.423369][ C1] ==================================================================[ 138.424317][ C1] BUG: KASAN: slab-out-of-bounds in ife_tlv_meta_encode (net/ife/ife.c:168)[ 138.424906][ C1] Write of size 4 at addr ffff8880077f4ffe by task ife_out_out_bou/255[ 138.425778][ C1] CPU: 1 UID: 0 PID: 255 Comm: ife_out_out_bou Not tainted 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(full)[ 138.425795][ C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011[ 138.425800][ C1] Call Trace:[ 138.425804][ C1] [ 138.425808][ C1] dump_stack_lvl (lib/dump_stack.c:122)[ 138.425828][ C1] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)[ 138.425839][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 138.425844][ C1] ? __virt_addr_valid (./arch/x86/include/asm/preempt.h:95 (discriminator 1) ./include/linux/rcupdate.h:975 (discriminator 1) ./include/linux/mmzone.h:2207 (discriminator 1) arch/x86/mm/physaddr.c:54 (discriminator 1))[ 138.425853][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168)[ 138.425859][ C1] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:597)[ 138.425868][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168)[ 138.425878][ C1] kasan_check_range (mm/kasan/generic.c:186 (discriminator 1) mm/kasan/generic.c:200 (discriminator 1))[ 138.425884][ C1] __asan_memset (mm/kasan/shadow.c:84 (discriminator 2))[ 138.425889][ C1] ife_tlv_meta_encode (net/ife/ife.c:168)[ 138.425893][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:171)[ 138.425898][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 138.425903][ C1] ife_encode_meta_u16 (net/sched/act_ife.c:57)[ 138.425910][ C1] ? __pfx_do_raw_spin_lock (kernel/locking/spinlock_debug.c:114)[ 138.425916][ C1] ? __asan_memcpy (mm/kasan/shadow.c:105 (discriminator 3))[ 138.425921][ C1] ? __pfx_ife_encode_meta_u16 (net/sched/act_ife.c:45)[ 138.425927][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 138.425931][ C1] tcf_ife_act (net/sched/act_ife.c:847 net/sched/act_ife.c:879)To solve this issue, fix the replace behavior by adding the metalist tothe ife rcu data structure.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: check metadata block offset is within rangeSyzkaller reports a "general protection fault in squashfs_copy_data"This is ultimately caused by a corrupted index look-up table, whichproduces a negative metadata block offset.This is subsequently passed to squashfs_copy_data (viasquashfs_read_metadata) where the negative offset causes an out of boundsaccess.The fix is to check that the offset is within range insquashfs_read_metadata. This will trap this and other cases.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()In DecodeQ931(), the UserUserIE code path reads a 16-bit length fromthe packet, then decrements it by 1 to skip the protocol discriminatorbyte before passing it to DecodeH323_UserInformation(). If the encodedlength is 0, the decrement wraps to -1, which is then passed as alarge value to the decoder, leading to an out-of-bounds read.Add a check to ensure len is positive after the decrement.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ecm: Fix net_device lifecycle with device_moveThe net_device is allocated during function instance creation andregistered during the bind phase with the gadget device as its sysfsparent. When the function unbinds, the parent device is destroyed, butthe net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directoryUse device_move() to reparent the net_device between the gadget devicetree and /sys/devices/virtual across bind and unbind cycles. During thefinal unbind, calling device_move(NULL) moves the net_device to thevirtual device tree before the gadget device is destroyed. On rebinding,device_move() reparents the device back under the new gadget, ensuringproper sysfs topology and power management ordering.To maintain compatibility with legacy composite drivers (e.g., multi.c),the bound flag is used to indicate whether the network device is sharedand pre-registered during the legacy driver's bind phase.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: Libgcrypt before 1.12.2 sometimes allows a heap-based buffer overflow and denial of service via crafted ECDH ciphertext to gcry_pk_decrypt.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- grub2 > 0-0 (version in image is 2.02-196.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()There's issue as follows:...EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): error count since last fsck: 1EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760...According to the log analysis, blocks are always requested from thecorrupted block group. This may happen as follows:ext4_mb_find_by_goal ext4_mb_load_buddy ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_wait_block_bitmap ext4_validate_block_bitmap if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp)) return -EFSCORRUPTED; // There's no logs. if (err) return err; // Will return errorext4_lock_group(ac->ac_sb, group); if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) // Unreachable goto out;After commit 9008a58e5dce ("ext4: make the bitmap read routines returnreal error codes") merged, Commit 163a203ddb36 ("ext4: mark block groupas corrupt on block bitmap error") is no real solution for allocatingblocks from corrupted block groups. This is because if'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then'ext4_mb_load_buddy()' may return an error. This means that the blockallocation will fail.Therefore, check block group if corrupted when ext4_mb_load_buddy()returns 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86-64: rename misleadingly named '__copy_user_nocache()' functionThis function was a masterclass in bad naming, for various historicalreasons.It claimed to be a non-cached user copy. It is literally _neither_ ofthose things. It's a specialty memory copy routine that usesnon-temporal stores for the destination (but not the source), and thatdoes exception handling for both source and destination accesses.Also note that while it works for unaligned targets, any unaligned parts(whether at beginning or end) will not use non-temporal stores, sinceonly words and quadwords can be non-temporal on x86.The exception handling means that it _can_ be used for user spaceaccesses, but not on its own - it needs all the normal "start user spaceaccess" logic around it.But typically the user space access would be the source, not thenon-temporal destination. That was the original intention of this,where the destination was some fragile persistent memory target thatneeded non-temporal stores in order to catch machine check exceptionssynchronously and deal with them gracefully.Thus that non-descriptive name: one use case was to copy from user spaceinto a non-cached kernel buffer. However, the existing users are a mixof that intended use-case, and a couple of random drivers that just didthis as a performance tweak.Some of those random drivers then actively misused the user copyingversion (with STAC/CLAC and all) to do kernel copies without ever evencaring about the exception handling, _just_ for the non-temporaldestination.Rename it as a first small step to actually make it halfway sane, andchange the prototype to be more normal: it doesn't take a user pointerunless the caller has done the proper conversion, and the argument sizeis the full size_t (it still won't actually copy more than 4GB in onego, but there's also no reason to silently truncate the size argument inthe caller).Finally, use this now sanely named function in the NTB code, whichmis-used a user copy version (with STAC/CLAC and all) of this interfacedespite it not actually being a user copy at all.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: fix freemap adjustments when adding xattrs to leaf blocksxfs/592 and xfs/794 both trip this assertion in the leaf block freemapadjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf));Upon enabling quite a lot more debugging code, I narrowed this down tofsstress trying to set a local extended attribute with namelen=3 andvaluelen=71. This results in an entry size of 80 bytes.At the start of xfs_attr3_leaf_add_work, the freemap looks like this:i 0 base 448 size 0 rhs 448 count 46i 1 base 388 size 132 rhs 448 count 46i 2 base 2120 size 4 rhs 448 count 46firstused = 520where "rhs" is the first byte past the end of the leaf entry array.This is inconsistent -- the entries array ends at byte 448, butfreemap[1] says there's free space starting at byte 388!By the end of the function, the freemap is in worse shape:i 0 base 456 size 0 rhs 456 count 47i 1 base 388 size 52 rhs 456 count 47i 2 base 2120 size 4 rhs 456 count 47firstused = 440Important note: 388 is not aligned with the entries array element sizeof 8 bytes.Based on the incorrect freemap, the name area starts at byte 440, whichis below the end of the entries array! That's why the assertiontriggers and the filesystem shuts down.How did we end up here? First, recall from the previous patch that thefreemap array in an xattr leaf block is not intended to be acomprehensive map of all free space in the leaf block. In other words,it's perfectly legal to have a leaf block with: * 376 bytes in use by the entries array * freemap[0] has [base = 376, size = 8] * freemap[1] has [base = 388, size = 1500] * the space between 376 and 388 is free, but the freemap stopped tracking that some time agoIf we add one xattr, the entries array grows to 384 bytes, andfreemap[0] becomes [base = 384, size = 0]. So far, so good. But if weadd a second xattr, the entries array grows to 392 bytes, and freemap[0]gets pushed up to [base = 392, size = 0]. This is bad, becausefreemap[1] hasn't been updated, and now the entries array and the freespace claim the same space.The fix here is to adjust all freemap entries so that none of themcollide with the entries array. Note that this fix relies on commit2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") andthe previous patch that resets zero length freemap entries to havebase = 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: delete attr leaf freemap entries when emptyBack in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.sizeunderflow"), Brian Foster observed that it's possible for a smallfreemap at the end of the end of the xattr entries array to experiencea size underflow when subtracting the space consumed by an expansion ofthe entries array. There are only three freemap entries, which meansthat it is not a complete index of all free space in the leaf block.This code can leave behind a zero-length freemap entry with a nonzerobase. Subsequent setxattr operations can increase the base up to thepoint that it overlaps with another freemap entry. This isn't in and ofitself a problem because the code in _leaf_add that finds free spaceignores any freemap entry with zero size.However, there's another bug in the freemap update code in _leaf_add,which is that it fails to update a freemap entry that begins midwaythrough the xattr entry that was just appended to the array. That canresult in the freemap containing two entries with the same base butdifferent sizes (0 for the "pushed-up" entry, nonzero for the entrythat's actually tracking free space). A subsequent _leaf_add can thenallocate xattr namevalue entries on top of the entries array, leading todata loss. But fixing that is for later.For now, eliminate the possibility of confusion by zeroing out the baseof any freemap entry that has zero size. Because the freemap is notintended to be a complete index of free space, a subsequent failure tofind any free space for a new xattr will trigger block compaction, whichregenerates the freemap.It looks like this bug has been in the codebase for quite a long 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:9p/xen: protect xen_9pfs_front_free against concurrent callsThe xenwatch thread can race with other back-end change notificationsand call xen_9pfs_front_free() twice, hitting the observed generalprotection fault due to a double-free. Guard the teardown path so onlyone caller can release the front-end state at a time, preventing thecrash.This is a fix for the following double-free:[ 27.052347] Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI[ 27.052357] CPU: 0 UID: 0 PID: 32 Comm: xenwatch Not tainted 6.18.0-02087-g51ab33fc0a8b-dirty #60 PREEMPT(none)[ 27.052363] RIP: e030:xen_9pfs_front_free+0x1d/0x150[ 27.052368] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 41 55 41 54 55 48 89 fd 48 c7 c7 48 d0 92 85 53 e8 cb cb 05 00 48 8b 45 08 48 8b 55 00 <48> 3b 28 0f 85 f9 28 35 fe 48 3b 6a 08 0f 85 ef 28 35 fe 48 89 42[ 27.052377] RSP: e02b:ffffc9004016fdd0 EFLAGS: 00010246[ 27.052381] RAX: 6b6b6b6b6b6b6b6b RBX: ffff88800d66e400 RCX: 0000000000000000[ 27.052385] RDX: 6b6b6b6b6b6b6b6b RSI: 0000000000000000 RDI: 0000000000000000[ 27.052389] RBP: ffff88800a887040 R08: 0000000000000000 R09: 0000000000000000[ 27.052393] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888009e46b68[ 27.052397] R13: 0000000000000200 R14: 0000000000000000 R15: ffff88800a887040[ 27.052404] FS: 0000000000000000(0000) GS:ffff88808ca57000(0000) knlGS:0000000000000000[ 27.052408] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033[ 27.052412] CR2: 00007f9714004360 CR3: 0000000004834000 CR4: 0000000000050660[ 27.052418] Call Trace:[ 27.052420] [ 27.052422] xen_9pfs_front_changed+0x5d5/0x720[ 27.052426] ? xenbus_otherend_changed+0x72/0x140[ 27.052430] ? __pfx_xenwatch_thread+0x10/0x10[ 27.052434] xenwatch_thread+0x94/0x1c0[ 27.052438] ? __pfx_autoremove_wake_function+0x10/0x10[ 27.052442] kthread+0xf8/0x240[ 27.052445] ? __pfx_kthread+0x10/0x10[ 27.052449] ? __pfx_kthread+0x10/0x10[ 27.052452] ret_from_fork+0x16b/0x1a0[ 27.052456] ? __pfx_kthread+0x10/0x10[ 27.052459] ret_from_fork_asm+0x1a/0x30[ 27.052463] [ 27.052465] Modules linked in:[ 27.052471] ---[ 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: chipidea: udc: fix DMA and SG cleanup in _ep_nuke()The ChipIdea UDC driver can encounter "not page aligned sg buffer"errors when a USB device is reconnected after being disconnectedduring an active transfer. This occurs because _ep_nuke() returnsrequests to the gadget layer without properly unmapping DMA buffersor cleaning up scatter-gather bounce buffers.Root cause:When a disconnect happens during a multi-segment DMA transfer, therequest's num_mapped_sgs field and sgt.sgl pointer remain set withstale values. The request is returned to the gadget driver with status-ESHUTDOWN but still has active DMA state. If the gadget driver reusesthis request on reconnect without reinitializing it, the stale DMAstate causes _hardware_enqueue() to skip DMA mapping (seeing non-zeronum_mapped_sgs) and attempt to use freed/invalid DMA addresses,leading to alignment errors and potential memory corruption.The normal completion path via _hardware_dequeue() properly callsusb_gadget_unmap_request_by_dev() and sglist_do_debounce() beforereturning the request. The _ep_nuke() path must do the same cleanupto ensure requests are returned in a clean, reusable state.Fix:Add DMA unmapping and bounce buffer cleanup to _ep_nuke() to mirrorthe cleanup sequence in _hardware_dequeue():- Call usb_gadget_unmap_request_by_dev() if num_mapped_sgs is set- Call sglist_do_debounce() with copy=false if bounce buffer existsThis ensures that when requests are returned due to endpoint shutdown,they don't retain stale DMA mappings. The 'false' parameter tosglist_do_debounce() prevents copying data back (appropriate forshutdown path where transfer was 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.302.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.32.1).
-
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.302.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.302.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.51.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.302.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:net: usb: cdc_ncm: add ndpoffset to NDP16 nframes bounds checkcdc_ncm_rx_verify_ndp16() validates that the NDP header and its DPEentries fit within the skb. The first check correctly accounts forndpoffset: if ((ndpoffset + sizeof(struct usb_cdc_ncm_ndp16)) > skb_in->len)but the second check omits it: if ((sizeof(struct usb_cdc_ncm_ndp16) + ret * (sizeof(struct usb_cdc_ncm_dpe16))) > skb_in->len)This validates the DPE array size against the total skb length as ifthe NDP were at offset 0, rather than at ndpoffset. When the NDP isplaced near the end of the NTB (large wNdpIndex), the DPE entries canextend past the skb data buffer even though the check passes.cdc_ncm_rx_fixup() then reads out-of-bounds memory when iteratingthe DPE array.Add ndpoffset to the nframes bounds check and use struct_size_t() toexpress the NDP-plus-DPE-array size more clearly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: log new dentries when logging parent dir of a conflicting inodeIf we log the parent directory of a conflicting inode, we are not loggingthe new dentries of the directory, so when we finish we have the parentdirectory's inode marked as logged but we did not log its new dentries.As a consequence if the parent directory is explicitly fsynced later andit does not have any new changes since we logged it, the fsync is a no-opand after a power failure the new dentries are missing.Example scenario: $ mkdir foo $ sync $rmdir foo $ mkdir dir1 $ mkdir dir2 # A file with the same name and parent as the directory we just deleted # and was persisted in a past transaction. So the deleted directory's # inode is a conflicting inode of this new file's inode. $ touch foo $ ln foo dir2/link # The fsync on dir2 will log the parent directory (".") because the # conflicting inode (deleted directory) does not exists anymore, but it # it does not log its new dentries (dir1). $ xfs_io -c "fsync" dir2 # This fsync on the parent directory is no-op, since the previous fsync # logged it (but without logging its new dentries). $ xfs_io -c "fsync" .
# After log replay dir1 is missing.Fix this by ensuring we log new dir dentries whenever we log the parentdirectory of a no longer existing conflicting inode.A test case for fstests will follow soon.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix krb5 mount with username optionCustomer reported that some of their krb5 mounts were failing againsta single server as the client was trying to mount the shares withwrong credentials. It turned out the client was reusing SMB sessionfrom first mount to try mounting the other shares, even though adifferent username= option had been specified to the other mounts.By using username mount option along with sec=krb5 to search forprincipals from keytab is supported by cifs.upcall(8) sincecifs-utils-4.8. So fix this by matching username mount option inmatch_session() even with Kerberos.For example, the second mount below should fail with -ENOKEY as thereis no 'foobar' principal in keytab (/etc/krb5.keytab). The clientends up reusing SMB session from first mount to perform the secondone, which is wrong.```$ ktutilktutil: add_entry -password -p testuser -k 1 -e aes256-ctsPassword for testuser@ZELDA.TEST:ktutil: write_kt /etc/krb5.keytabktutil: quit$ klist -keKeytab name: FILE:/etc/krb5.keytabKVNO Principal ---- ---------------------------------------------------------------- 1 testuser@ZELDA.TEST (aes256-cts-hmac-sha1-96)$ mount.cifs //w22-root2/scratch /mnt/1 -o sec=krb5,username=testuser$ mount.cifs //w22-root2/scratch /mnt/2 -o sec=krb5,username=foobar$ mount -t cifs | grep -Po 'username=\K\w+'testusertestuser```
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: macb: fix use-after-free access to PTP clockPTP clock is registered on every opening of the interface and destroyed onevery closing. However it may be accessed via get_ts_info ethtool callwhich is possible while the interface is just present in the kernel.BUG: KASAN: use-after-free in ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426Read of size 4 at addr ffff8880194345cc by task syz.0.6/948CPU: 1 PID: 948 Comm: syz.0.6 Not tainted 6.1.164+ #109Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xba lib/dump_stack.c:106 print_address_description mm/kasan/report.c:316 [inline] print_report+0x17f/0x496 mm/kasan/report.c:420 kasan_report+0xd9/0x180 mm/kasan/report.c:524 ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 gem_get_ts_info+0x138/0x1e0 drivers/net/ethernet/cadence/macb_main.c:3349 macb_get_ts_info+0x68/0xb0 drivers/net/ethernet/cadence/macb_main.c:3371 __ethtool_get_ts_info+0x17c/0x260 net/ethtool/common.c:558 ethtool_get_ts_info net/ethtool/ioctl.c:2367 [inline] __dev_ethtool net/ethtool/ioctl.c:3017 [inline] dev_ethtool+0x2b05/0x6290 net/ethtool/ioctl.c:3095 dev_ioctl+0x637/0x1070 net/core/dev_ioctl.c:510 sock_do_ioctl+0x20d/0x2c0 net/socket.c:1215 sock_ioctl+0x577/0x6d0 net/socket.c:1320 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+0x18c/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 457: kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:699 [inline] ptp_clock_register+0x144/0x10e0 drivers/ptp/ptp_clock.c:235 gem_ptp_init+0x46f/0x930 drivers/net/ethernet/cadence/macb_ptp.c:375 macb_open+0x901/0xd10 drivers/net/ethernet/cadence/macb_main.c:2920 __dev_open+0x2ce/0x500 net/core/dev.c:1501 __dev_change_flags+0x56a/0x740 net/core/dev.c:8651 dev_change_flags+0x92/0x170 net/core/dev.c:8722 do_setlink+0xaf8/0x3a80 net/core/rtnetlink.c:2833 __rtnl_newlink+0xbf4/0x1940 net/core/rtnetlink.c:3608 rtnl_newlink+0x63/0xa0 net/core/rtnetlink.c:3655 rtnetlink_rcv_msg+0x3c6/0xed0 net/core/rtnetlink.c:6150 netlink_rcv_skb+0x15d/0x430 net/netlink/af_netlink.c:2511 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x6d7/0xa30 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x97e/0xeb0 net/netlink/af_netlink.c:1872 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x14b/0x180 net/socket.c:730 __sys_sendto+0x320/0x3b0 net/socket.c:2152 __do_sys_sendto net/socket.c:2164 [inline] __se_sys_sendto net/socket.c:2160 [inline] __x64_sys_sendto+0xdc/0x1b0 net/socket.c:2160 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8Freed by task 938: kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1729 [inline] slab_free_freelist_hook mm/slub.c:1755 [inline] slab_free mm/slub.c:3687 [inline] __kmem_cache_free+0xbc/0x320 mm/slub.c:3700 device_release+0xa0/0x240 drivers/base/core.c:2507 kobject_cleanup lib/kobject.c:681 [inline] kobject_release lib/kobject.c:712 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1cd/0x350 lib/kobject.c:729 put_device+0x1b/0x30 drivers/base/core.c:3805 ptp_clock_unregister+0x171/0x270 drivers/ptp/ptp_clock.c:391 gem_ptp_remove+0x4e/0x1f0 drivers/net/ethernet/cadence/macb_ptp.c:404 macb_close+0x1c8/0x270 drivers/net/ethernet/cadence/macb_main.c:2966 __dev_close_many+0x1b9/0x310 net/core/dev.c:1585 __dev_close net/core/dev.c:1597 [inline] __dev_change_flags+0x2bb/0x740 net/core/dev.c:8649 dev_change_fl---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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udp: Fix wildcard bind conflict check when using hash2When binding a udp_sock to a local address and port, UDP usestwo hashes (udptable->hash and udptable->hash2) for collisiondetection. The current code switches to "hash2" whenhslot->count > 10."hash2" is keyed by local address and local port."hash" is keyed by local port only.The issue can be shown in the following bind sequence (pseudo code):bind(fd1, "[fd00::1]:8888")bind(fd2, "[fd00::2]:8888")bind(fd3, "[fd00::3]:8888")bind(fd4, "[fd00::4]:8888")bind(fd5, "[fd00::5]:8888")bind(fd6, "[fd00::6]:8888")bind(fd7, "[fd00::7]:8888")bind(fd8, "[fd00::8]:8888")bind(fd9, "[fd00::9]:8888")bind(fd10, "[fd00::10]:8888")/* Correctly return -EADDRINUSE because "hash" is used * instead of "hash2". udp_lib_lport_inuse() detects the * conflict. */bind(fail_fd, "[::]:8888")/* After one more socket is bound to "[fd00::11]:8888", * hslot->count exceeds 10 and "hash2" is used instead. */bind(fd11, "[fd00::11]:8888")bind(fail_fd, "[::]:8888") /* succeeds unexpectedly */The same issue applies to the IPv4 wildcard address "0.0.0.0"and the IPv4-mapped wildcard address "::ffff:0.0.0.0". Forexample, if there are existing sockets bound to"192.168.1.[1-11]:8888", then binding "0.0.0.0:8888" or"[::ffff:0.0.0.0]:8888" can also miss the conflict whenhslot->count > 10.TCP inet_csk_get_port() already has the correct check ininet_use_bhash2_on_bind(). Rename it toinet_use_hash2_on_bind() and move it to inet_hashtables.hso udp.c can reuse it in this 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_hid: don't call cdev_init while cdev in useWhen calling unbind, then bind again, cdev_init reinitialized the cdev,even though there may still be references to it. That's the case whenthe /dev/hidg* device is still opened. This obviously unsafe behaviorlike oopes.This fixes this by using cdev_alloc to put the cdev on the heap. Thatway, we can simply allocate a new one in hidg_bind.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: renesas_usb3: validate endpoint index in standard request handlersThe GET_STATUS and SET/CLEAR_FEATURE handlers extract the endpointnumber from the host-supplied wIndex without any sort of validation.Fix this up by validating the number of endpoints actually match up withthe number the device has before attempting to dereference a pointerbased on this math.This is just like what was done in commit ee0d382feb44 ("usb: gadget:aspeed_udc: validate endpoint index for ast udc") for the aspeed 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete()A broken/bored/mean USB host can overflow the skb_shared_info->frags[]array on a Linux gadget exposing a Phonet function by sending anunbounded sequence of full-page OUT transfers.pn_rx_complete() finalizes the skb only when req->actual < req->length,where req->length is set to PAGE_SIZE by the gadget. If the host alwayssends exactly PAGE_SIZE bytes per transfer, fp->rx.skb will never bereset and each completion will add another fragment viaskb_add_rx_frag(). Once nr_frags exceeds MAX_SKB_FRAGS (default 17),subsequent frag stores overwrite memory adjacent to the shinfo on theheap.Drop the skb and account a length error when the frag limit is reached,matching the fix applied in t7xx by commit f0813bcd2d9d ("net: wwan:t7xx: fix potential skb->frags overflow in RX 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb()The block_len read from the host-supplied NTB header is checked againstntb_max but has no lower bound. When block_len is smaller thanopts->ndp_size, the bounds check of: ndp_index > (block_len - opts->ndp_size)will underflow producing a huge unsigned value that ndp_index can neverexceed, defeating the check entirely.The same underflow occurs in the datagram index checks against block_len- opts->dpe_size. With those checks neutered, a malicious USB host canchoose ndp_index and datagram offsets that point past the actualtransfer, and the skb_put_data() copies adjacent kernel memory into thenetwork skb.Fix this by rejecting block lengths that cannot hold at least the NTBheader plus one NDP. This will make block_len - opts->ndp_size andblock_len - opts->dpe_size both well-defined.Commit 8d2b1a1ec9f5 ("CDC-NCM: avoid overflow in sanity checking") fixeda related class of issues on the host side of NCM.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: fireworks: bound device-supplied status before string array lookupThe status field in an EFW response is a 32-bit value supplied by thefirewire device. efr_status_names[] has 17 entries so a status valueoutside that range goes off into the weeds when looking at the %s value.Even worse, the status could return EFR_STATUS_INCOMPLETE which is0x80000000, and is obviously not in that array of potential strings.Fix this up by properly bounding the index against the array size andprinting "unknown" if it's not recognized.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_rndis: Fix net_device lifecycle with device_moveThe net_device is allocated during function instance creation andregistered during the bind phase with the gadget device as its sysfsparent. When the function unbinds, the parent device is destroyed, butthe net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directoryUse device_move() to reparent the net_device between the gadget devicetree and /sys/devices/virtual across bind and unbind cycles. During thefinal unbind, calling device_move(NULL) moves the net_device to thevirtual device tree before the gadget device is destroyed. On rebinding,device_move() reparents the device back under the new gadget, ensuringproper sysfs topology and power management ordering.To maintain compatibility with legacy composite drivers (e.g., multi.c),the borrowed_net flag is used to indicate whether the network device isshared and pre-registered during the legacy driver's bind phase.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_subset: Fix net_device lifecycle with device_moveThe net_device is allocated during function instance creation andregistered during the bind phase with the gadget device as its sysfsparent. When the function unbinds, the parent device is destroyed, butthe net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directoryUse device_move() to reparent the net_device between the gadget devicetree and /sys/devices/virtual across bind and unbind cycles. During thefinal unbind, calling device_move(NULL) moves the net_device to thevirtual device tree before the gadget device is destroyed. On rebinding,device_move() reparents the device back under the new gadget, ensuringproper sysfs topology and power management ordering.To maintain compatibility with legacy composite drivers (e.g., multi.c),the bound flag is used to indicate whether the network device is sharedand pre-registered during the legacy driver's bind phase.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_eem: Fix net_device lifecycle with device_moveThe net_device is allocated during function instance creation andregistered during the bind phase with the gadget device as its sysfsparent. When the function unbinds, the parent device is destroyed, butthe net_device survives, resulting in dangling sysfs symlinks:console:/ # ls -l /sys/class/net/usb0lrwxrwxrwx ... /sys/class/net/usb0 ->/sys/devices/platform/.../gadget.0/net/usb0console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0ls: .../gadget.0/net/usb0: No such file or directoryUse device_move() to reparent the net_device between the gadget devicetree and /sys/devices/virtual across bind and unbind cycles. During thefinal unbind, calling device_move(NULL) moves the net_device to thevirtual device tree before the gadget device is destroyed. On rebinding,device_move() reparents the device back under the new gadget, ensuringproper sysfs topology and power management ordering.To maintain compatibility with legacy composite drivers (e.g., multi.c),the bound flag is used to indicate whether the network device is sharedand pre-registered during the legacy driver's bind phase.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: caiaq: fix stack out-of-bounds read in init_cardThe loop creates a whitespace-stripped copy of the card shortnamewhere `len < sizeof(card->id)` is used for the bounds check. Sincesizeof(card->id) is 16 and the local id buffer is also 16 bytes,writing 16 non-space characters fills the entire buffer,overwriting the terminating nullbyte.When this non-null-terminated string is later passed tosnd_card_set_id() -> copy_valid_id_string(), the function scansforward with `while (*nid && ...)` and reads past the end of thestack buffer, reading the contents of the stack.A USB device with a product name containing many non-ASCII, non-spacecharacters (e.g. multibyte UTF-8) will reliably trigger this as follows: BUG: KASAN: stack-out-of-bounds in copy_valid_id_string sound/core/init.c:696 [inline] BUG: KASAN: stack-out-of-bounds in snd_card_set_id_no_lock+0x698/0x74c sound/core/init.c:718The off-by-one has been present since commit bafeee5b1f8d ("ALSA:snd_usb_caiaq: give better shortname") from June 2009 (v2.6.31-rc1),which first introduced this whitespace-stripping loop. The originalcode never accounted for the null terminator when bounding the copy.Fix this by changing the loop bound to `sizeof(card->id) - 1`,ensuring at least one byte remains as the null terminator.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: A flaw was found in GNU Binutils. This heap-based buffer overflow vulnerability, specifically an out-of-bounds read in the bfd linker, allows an attacker to gain access to sensitive information. By convincing a user to process a specially crafted XCOFF object file, an attacker can trigger this flaw, potentially leading to information disclosure or an application level denial of service.
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 GNU Binutils. This vulnerability, a heap-based buffer overflow, specifically an out-of-bounds read, exists in the bfd linker component. An attacker could exploit this by convincing a user to process a specially crafted malicious XCOFF object file. Successful exploitation may lead to the disclosure of sensitive information or cause the application to crash, resulting in an application level denial of service.
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: Unknown.
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:wifi: mac80211: check tdls flag in ieee80211_tdls_operWhen NL80211_TDLS_ENABLE_LINK is called, the code only checks if thestation exists but not whether it is actually a TDLS station. Thisallows the operation to proceed for non-TDLS stations, causingunintended side effects like modifying channel context and HTprotection before failing.Add a check for sta->sta.tdls early in the ENABLE_LINK case, beforeany side effects occur, to ensure the operation is only allowed foractual TDLS peers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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.48.4).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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.302.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.302.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.62.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: me4000: Fix potential overrun of firmware buffer`me4000_xilinx_download()` loads the firmware that was requested by`request_firmware()`. It is possible for it to overrun the sourcebuffer because it blindly trusts the file format. It reads a datastream length from the first 4 bytes into variable `file_length` andreads the data stream contents of length `file_length` from offset 16onwards.Add a test to ensure that the supplied firmware is long enough tocontain the header and the data stream. On failure, log an error andreturn `-EINVAL`.Note: The firmware loading was totally broken before commit ac584af59945("staging: comedi: me4000: fix firmware downloading"), but that is themost sensible target for this 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: me_daq: Fix potential overrun of firmware buffer`me2600_xilinx_download()` loads the firmware that was requested by`request_firmware()`. It is possible for it to overrun the sourcebuffer because it blindly trusts the file format. It reads a datastream length from the first 4 bytes into variable `file_length` andreads the data stream contents of length `file_length` from offset 16onwards. Although it checks that the supplied firmware is at least 16bytes long, it does not check that it is long enough to contain the datastream.Add a test to ensure that the supplied firmware is long enough tocontain the header and the data stream. On failure, log an error andreturn `-EINVAL`.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: Vim is an open source, command line text editor. Prior to 9.2.0316, a command injection vulnerability in Vim's netbeans interface allows a malicious netbeans server to execute arbitrary Ex commands when Vim connects to it, via unsanitized strings in the defineAnnoType and specialKeys protocol messages. This vulnerability is fixed in 9.2.0316.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- vim > 0-0 (version in image is 9.2.0280-17.62.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: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.302.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.26.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.52.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: 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.302.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.17.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.99.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabledWhen booting with the 'ipv6.disable=1' parameter, the nd_tbl is neverinitialized because inet6_init() exits before ndisc_init() is calledwhich initializes it. If an IPv6 packet is injected into the interface,route_shortcircuit() is called and a NULL pointer dereference happens onneigh_lookup(). BUG: kernel NULL pointer dereference, address: 0000000000000380 Oops: Oops: 0000 [#1] SMP NOPTI [...] RIP: 0010:neigh_lookup+0x20/0x270 [...] Call Trace: vxlan_xmit+0x638/0x1ef0 [vxlan] dev_hard_start_xmit+0x9e/0x2e0 __dev_queue_xmit+0xbee/0x14e0 packet_sendmsg+0x116f/0x1930 __sys_sendto+0x1f5/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x12f/0x1590 entry_SYSCALL_64_after_hwframe+0x76/0x7eFix this by adding an early check on route_shortcircuit() when protocolis ETH_P_IPV6. Note that ipv6_mod_enabled() cannot be used here becauseVXLAN can be built-in even when IPv6 is built as a module.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: Issue summary: During processing of a crafted CMS EnvelopedData messagewith KeyTransportRecipientInfo a NULL pointer dereference can happen.Impact summary: Applications that process attacker-controlled CMS data maycrash before authentication or cryptographic operations occur resulting inDenial of Service.When a CMS EnvelopedData message that uses KeyTransportRecipientInfo withRSA-OAEP encryption is processed, the optional parameters field ofRSA-OAEP SourceFunc algorithm identifier is examined without checkingfor its presence. This results in a NULL pointer dereference if the fieldis missing.Applications and services that call CMS_decrypt() on untrusted input(e.g., S/MIME processing or CMS-based protocols) are vulnerable.The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by thisissue, as the affected code is outside the OpenSSL FIPS module boundary.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libopenssl1_0_0 > 0-0 (version in image is 1.0.2p-3.106.1).
-
Description: In MIT Kerberos 5 (aka krb5) before 1.22.3, there is a NULL pointer dereference if an application calls gss_accept_sec_context() on a system with a NegoEx mechanism registered in /etc/gss/mech. An unauthenticated remote attacker can trigger this, causing the process to terminate in parse_nego_message.
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: In MIT Kerberos 5 (aka krb5) before 1.22.3, there is an integer underflow and resultant out-of-bounds read if an application calls gss_accept_sec_context() on a system with a NegoEx mechanism registered in /etc/gss/mech. An unauthenticated remote attacker can trigger this, possibly causing the process to terminate in parse_message.
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: lxml is a library for processing XML and HTML in the Python language. Prior to 6.1.0, using either of the two parsers in the default configuration (with resolve_entities=True) allows untrusted XML input to read local files. Setting the resolve_entities option explicitly to resolve_entities='internal' or resolve_entities=False disables the local file access. This vulnerability is fixed in 6.1.0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python3-lxml > 0-0 (version in image is 3.6.1-3.6.1).
-
Description: Unknown.
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: Calling the scanf family of functions with a %mc (malloc'd character match) in the GNU C Library version 2.7 to version 2.43 with a format width specifier with an explicit width greater than 1024 could result in a one byte heap buffer overflow.
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.43.1).
-
Description: curl might erroneously pass on credentials for a first proxy to a secondproxy.This can happen when the following conditions are true:1. curl is setup to use specific different proxies for different URL schemes2. the first proxy needs credentials3. the second proxy uses no credentials4. while using the first proxy (using say `http://`), curl is asked to follow a redirect to a URL using another scheme (say `https://`), accessed using a second, different, proxy
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.120.1).
-
Description: When asked to both use a `.netrc` file for credentials and to follow HTTPredirects, libcurl could leak the password used for the first host to thefollowed-to host under certain circumstances.
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.120.1).
-
Description: Successfully using libcurl to do a transfer over a specific HTTP proxy(`proxyA`) with **Digest** authentication and then changing the proxy host toa second one (`proxyB`) for a second transfer, reusing the same handle, makeslibcurl wrongly pass on the `Proxy-Authorization:` header field meant for`proxyA`, to `proxyB`.
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.120.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.302.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.302.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.302.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix use-after-free in iscsit_dec_session_usage_count()In iscsit_dec_session_usage_count(), the function calls complete() whileholding the sess->session_usage_lock. Similar to the connection usage countlogic, the waiter signaled by complete() (e.g., in the session releasepath) may wake up and free the iscsit_session structure immediately.This creates a race condition where the current thread may attempt toexecute spin_unlock_bh() on a session structure that has already beendeallocated, resulting in a KASAN slab-use-after-free.To resolve this, release the session_usage_lock before calling complete()to ensure all dereferences of the sess pointer are finished before thewaiter is allowed to proceed with deallocation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix transaction abort when snapshotting received subvolumesCurrently a user can trigger a transaction abort by snapshotting apreviously received snapshot a bunch of times until we reach aBTRFS_UUID_KEY_RECEIVED_SUBVOL item overflow (the maximum item size wecan store in a leaf). This is very likely not common in practice, butif it happens, it turns the filesystem into RO mode. The snapshot, sendand set_received_subvol and subvol_setflags (used by receive) don'trequire CAP_SYS_ADMIN, just inode_owner_or_capable(). A malicious usercould use this to turn a filesystem into RO mode and disrupt a system.Reproducer script: $ cat test.sh #!/bin/bash DEV=/dev/sdi MNT=/mnt/sdi # Use smallest node size to make the test faster. mkfs.btrfs -f --nodesize 4K $DEV mount $DEV $MNT # Create a subvolume and set it to RO so that it can be used for send. btrfs subvolume create $MNT/sv touch $MNT/sv/foo btrfs property set $MNT/sv ro true # Send and receive the subvolume into snaps/sv. mkdir $MNT/snaps btrfs send $MNT/sv | btrfs receive $MNT/snaps # Now snapshot the received subvolume, which has a received_uuid, a # lot of times to trigger the leaf overflow. total=500 for ((i = 1; i <= $total; i++)); do echo -ne "\rCreating snapshot $i/$total" btrfs subvolume snapshot -r $MNT/snaps/sv $MNT/snaps/sv_$i > /dev/null done echo umount $MNTWhen running the test: $ ./test.sh (...) Create subvolume '/mnt/sdi/sv' At subvol /mnt/sdi/sv At subvol sv Creating snapshot 496/500ERROR: Could not create subvolume: Value too large for defined data type Creating snapshot 497/500ERROR: Could not create subvolume: Read-only file system Creating snapshot 498/500ERROR: Could not create subvolume: Read-only file system Creating snapshot 499/500ERROR: Could not create subvolume: Read-only file system Creating snapshot 500/500ERROR: Could not create subvolume: Read-only file systemAnd in dmesg/syslog: $ dmesg (...) [251067.627338] BTRFS warning (device sdi): insert uuid item failed -75 (0x4628b21c4ac8d898, 0x2598bee2b1515c91) type 252! [251067.629212] ------------[ cut here ]------------ [251067.630033] BTRFS: Transaction aborted (error -75) [251067.630871] WARNING: fs/btrfs/transaction.c:1907 at create_pending_snapshot.cold+0x52/0x465 [btrfs], CPU#10: btrfs/615235 [251067.632851] Modules linked in: btrfs dm_zero (...) [251067.644071] CPU: 10 UID: 0 PID: 615235 Comm: btrfs Tainted: G W 6.19.0-rc8-btrfs-next-225+ #1 PREEMPT(full) [251067.646165] Tainted: [W]=WARN [251067.646733] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [251067.648735] RIP: 0010:create_pending_snapshot.cold+0x55/0x465 [btrfs] [251067.649984] Code: f0 48 0f (...) [251067.653313] RSP: 0018:ffffce644908fae8 EFLAGS: 00010292 [251067.653987] RAX: 00000000ffffff01 RBX: ffff8e5639e63a80 RCX: 00000000ffffffd3 [251067.655042] RDX: ffff8e53faa76b00 RSI: 00000000ffffffb5 RDI: ffffffffc0919750 [251067.656077] RBP: ffffce644908fbd8 R08: 0000000000000000 R09: ffffce644908f820 [251067.657068] R10: ffff8e5adc1fffa8 R11: 0000000000000003 R12: ffff8e53c0431bd0 [251067.658050] R13: ffff8e5414593600 R14: ffff8e55efafd000 R15: 00000000ffffffb5 [251067.659019] FS: 00007f2a4944b3c0(0000) GS:ffff8e5b27dae000(0000) knlGS:0000000000000000 [251067.660115] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [251067.660943] CR2: 00007ffc5aa57898 CR3: 00000005813a2003 CR4: 0000000000370ef0 [251067.661972] Call Trace: [251067.662292] [251067.662653] create_pending_snapshots+0x97/0xc0 [btrfs] [251067.663413] btrfs_commit_transaction+0x26e/0xc00 [btrfs] [251067.664257] ? btrfs_qgroup_convert_reserved_meta+0x35/0x390 [btrfs] [251067.665238] ? _raw_spin_unlock+0x15/0x30 [251067.665837] ? record_root_---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.302.1).
-
Description: pip prior to version 26.1 would run self-update check functionality after installing wheel files which required importing well-known Python modules names. These module imports were intentionally deferred to increase startup time of the pip CLI. The patch changes self-update functionality to run before wheels are installed to prevent newly-installed modules from being imported shortly after the installation of a wheel package. Users should still review package contents prior to installation.
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.74.1).
-
Description: Calling the ungetwc function on a FILE stream with wide characters encoded in a character set that has overlaps between its single byte and multi-byte character encodings, in the GNU C Library version 2.43 or earlier, may result in an attempt to read bytes before an allocated buffer, potentially resulting in unintentional disclosure of neighboring data in the heap, or a program crash.A bug in the wide character pushback implementation (_IO_wdefault_pbackfail in libio/wgenops.c) causes ungetwc() to operate on the regular character buffer (fp->_IO_read_ptr) instead of the actual wide-stream read pointer (fp->_wide_data->_IO_read_ptr). The program crash may happen in cases where fp->_IO_read_ptr is not initialized and hence points to NULL. The buffer under-read requires a special situation where the input character encoding is such that there are overlaps between single byte representations and multibyte representations in that encoding, resulting in spurious matches. The spurious match case is not possible in the standard Unicode character sets.
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.43.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.99.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.2.0280-17.62.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_netem: fix out-of-bounds access in packet corruptionIn netem_enqueue(), the packet corruption logic usesget_random_u32_below(skb_headlen(skb)) to select an index formodifying skb->data. When an AF_PACKET TX_RING sends fully non-linearpackets over an IPIP tunnel, skb_headlen(skb) evaluates to 0.Passing 0 to get_random_u32_below() takes the variable-ceil slow pathwhich returns an unconstrained 32-bit random integer. Using thisunconstrained value as an offset into skb->data results in anout-of-bounds memory access.Fix this by verifying skb_headlen(skb) is non-zero before attemptingto corrupt the linear data area. Fully non-linear packets will silentlybypass the corruption logic.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: only handle RESPONSE during service challengeOnly process RESPONSE packets while the service connection is still inRXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock beforerunning response verification and security initialization, then use a localsecured flag to decide whether to queue the secured-connection work afterthe state transition. This keeps duplicate or late RESPONSE packets fromre-running the setup path and removes the unlocked post-transition statetest.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: A flaw was found in util-linux. Improper hostname canonicalization in the `login(1)` utility, when invoked with the `-h` option, can modify the supplied remote hostname before setting `PAM_RHOST`. A remote attacker could exploit this by providing a specially crafted hostname, potentially bypassing host-based Pluggable Authentication Modules (PAM) access control rules that rely on fully qualified domain names. This could lead to unauthorized access.
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.51.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply()This patch fixes an out-of-bounds access in ceph_handle_auth_reply()that can be triggered by a message of type CEPH_MSG_AUTH_REPLY. Inceph_handle_auth_reply(), the value of the payload_len field of such amessage is stored in a variable of type int. A value greater thanINT_MAX leads to an integer overflow and is interpreted as a negativevalue. This leads to decrementing the pointer address by this value andsubsequently accessing it because ceph_decode_need() only checks thatthe memory access does not exceed the end address of the allocation.This patch fixes the issue by changing the data type of payload_len tou32. Additionally, the data type of result_msg_len is changed to u32,as it is also a variable holding a non-negative length.Also, an additional layer of sanity checks is introduced, ensuring thatdirectly after reading it from the message, payload_len andresult_msg_len are not greater than the overall segment length.BUG: KASAN: slab-out-of-bounds in ceph_handle_auth_reply+0x642/0x7a0 [libceph]Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014Workqueue: ceph-msgr ceph_con_workfn [libceph]Call Trace: dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x620 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x72/0x210 kasan_report+0xe7/0x130 ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] __asan_report_load_n_noabort+0xf/0x20 ceph_handle_auth_reply+0x642/0x7a0 [libceph] mon_dispatch+0x973/0x23d0 [libceph] ? apparmor_socket_recvmsg+0x6b/0xa0 ? __pfx_mon_dispatch+0x10/0x10 [libceph] ? __kasan_check_write+0x14/0x30i ? mutex_unlock+0x7f/0xd0 ? __pfx_mutex_unlock+0x10/0x10 ? __pfx_do_recvmsg+0x10/0x10 [libceph] ceph_con_process_message+0x1f1/0x650 [libceph] process_message+0x1e/0x450 [libceph] ceph_con_v2_try_read+0x2e48/0x6c80 [libceph] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph] ? save_fpregs_to_fpstate+0xb0/0x230 ? raw_spin_rq_unlock+0x17/0xa0 ? finish_task_switch.isra.0+0x13b/0x760 ? __switch_to+0x385/0xda0 ? __kasan_check_write+0x14/0x30 ? mutex_lock+0x8d/0xe0 ? __pfx_mutex_lock+0x10/0x10 ceph_con_workfn+0x248/0x10c0 [libceph] process_one_work+0x629/0xf80 ? __kasan_check_write+0x14/0x30 worker_thread+0x87f/0x1570 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx_try_to_wake_up+0x10/0x10 ? kasan_print_address_stack_frame+0x1f7/0x280 ? __pfx_worker_thread+0x10/0x10 kthread+0x396/0x830 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? __pfx_kthread+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? recalc_sigpending+0x180/0x210 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3f7/0x610 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x385/0xda0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 [ idryomov: replace if statements with ceph_decode_need() for payload_len and result_msg_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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs/xattr: missing fdput() in fremovexattr error pathIn the Linux kernel, the fremovexattr() syscall calls fdget() to acquire afile reference but returns early without calling fdput() whenstrncpy_from_user() fails on the name argument. In multi-threaded processeswhere fdget() takes the slow path, this permanently leaks onefile reference per call, pinning the struct file and associated kernelobjects in memory. An unprivileged local user can exploit this to causekernel memory exhaustion. The issue was inadvertently fixed by commita71874379ec8 ("xattr: switch to CLASS(fd)").
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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: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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.1).
-
Description: A transient execution vulnerability within AMD CPUs may allow a local user-privileged attacker to leak data via the floating point divisor unit, potentially resulting in loss of confidentiality.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.39.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.302.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.302.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.302.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.302.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: only set free_cpus for online runqueuesCommit 16b269436b72 ("sched/deadline: Modify cpudl::free_cpusto reflect rd->online") introduced the cpudl_set/clear_freecpufunctions to allow the cpu_dl::free_cpus mask to be manipulatedby the deadline scheduler class rq_on/offline callbacks so themask would also reflect this state.Commit 9659e1eeee28 ("sched/deadline: Remove cpu_active_maskfrom cpudl_find()") removed the check of the cpu_active_mask tosave some processing on the premise that the cpudl::free_cpusmask already reflected the runqueue online state.Unfortunately, there are cases where it is possible for thecpudl_clear function to set the free_cpus bit for a CPU when thedeadline runqueue is offline. When this occurs while a CPU isconnected to the default root domain the flag may retain the badstate after the CPU has been unplugged. Later, a different CPUthat is transitioning through the default root domain may push adeadline task to the powered down CPU when cpudl_find sees itsfree_cpus bit is set. If this happens the task will not have theopportunity to run.One example is outlined here:https://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.comAnother occurs when the last deadline task is migrated from aCPU that has an offlined runqueue. The dequeue_task member ofthe deadline scheduler class will eventually call cpudl_clearand set the free_cpus bit for the CPU.This commit modifies the cpudl_clear function to be aware of theonline state of the deadline runqueue so that the free_cpus maskcan be updated appropriately.It is no longer necessary to manage the mask outside of thecpudl_set/clear functions so the cpudl_set/clear_freecpufunctions are removed. In addition, since the free_cpus mask isnow only updated under the cpudl lock the code was changed touse the non-atomic __cpumask functions.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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.302.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.302.1).
-
Description: An issue was discovered in Binutils before 2.46. The objdump contains a denial-of-service vulnerability when processing a crafted binary with malformed debug information. A logic flaw in the handling of DWARF location list headers can cause objdump to enter an unbounded loop and produce endless output until manually interrupted. This issue affects versions prior to the upstream fix and allows a local attacker to cause excessive resource consumption by supplying a malicious input 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: Binutils objdump contains a denial-of-service vulnerability when processing a crafted binary with malformed DWARF debug_rnglists data. A logic error in the handling of the debug_rnglists header can cause objdump to repeatedly print the same warning message and fail to terminate, resulting in an unbounded logging loop until the process is interrupted. The issue was observed in binutils 2.44. A local attacker can exploit this vulnerability by supplying a malicious input file, leading to excessive CPU and I/O usage and preventing completion of the objdump analysis.
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: GNU Binutils thru 2.45.1 readelf contains a denial-of-service vulnerability when processing a crafted binary with malformed DWARF loclists data. A logic flaw in the DWARF parsing code can cause readelf to repeatedly print the same table output without making forward progress, resulting in an unbounded output loop that never terminates unless externally interrupted. A local attacker can trigger this behavior by supplying a malicious input file, causing excessive CPU and I/O usage and preventing readelf from completing its analysis.
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: GNU Binutils thru 2.45.1 readelf contains a denial-of-service vulnerability when processing a crafted binary with malformed DWARF .debug_rnglists data. A logic flaw in the DWARF parsing path causes readelf to repeatedly print the same warning message without making forward progress, resulting in a non-terminating output loop that requires manual interruption. No evidence of memory corruption or code execution was observed.
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: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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:memory: mtk-smi: fix device leak on larb probeMake sure to drop the reference taken when looking up the SMI deviceduring larb probe on late probe failure (e.g. probe deferral) and ondriver unbind.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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.74.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: make calc_target() set t->paused, not just clear itCurrently calc_target() clears t->paused if the request shouldn't bepaused anymore, but doesn't ever set t->paused even though it's able todetermine when the request should be paused. Setting t->paused is leftto __submit_request() which is fine for regular requests but doesn'twork for linger requests -- since __submit_request() doesn't operateon linger requests, there is nowhere for lreq->t.paused to be set.One consequence of this is that watches don't get reestablished onpaused -> unpaused transitions in cases where requests have been pausedlong enough for the (paused) unwatch request to time out and for thesubsequent (re)watch request to enter the paused state. On top of thewatch not getting reestablished, rbd_reregister_watch() gets stuck withrbd_dev->watch_mutex held: rbd_register_watch __rbd_register_watch ceph_osdc_watch linger_reg_commit_waitIt's waiting for lreq->reg_commit_wait to be completed, but for that tohappen the respective request needs to end up on need_resend_linger listand be kicked when requests are unpaused. There is no chance for thatif the request in question is never marked paused in the first place.The fact that rbd_dev->watch_mutex remains taken out forever thenprevents the image from getting unmapped -- "rbd unmap" would inevitablyhang in D state on an attempt to grab the 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panelThe connector type for the DataImage SCF0700C48GGU18 panel is missing anddevm_drm_panel_bridge_add() requires connector type to be set. This leadsto a warning and a backtrace in the kernel log and panel does not work:"WARNING: CPU: 3 PID: 38 at drivers/gpu/drm/bridge/panel.c:379 devm_drm_of_get_bridge+0xac/0xb8"The warning is triggered by a check for valid connector type indevm_drm_panel_bridge_add(). If there is no valid connector typeset for a panel, the warning is printed and panel is not added.Fill in the missing connector type to fix the warning and makethe panel operational once again.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leakFix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:gs_usb_receive_bulk_callback(): fix URB memory leak").In esd_usb_open(), the URBs for USB-in transfers are allocated, added tothe dev->rx_submitted anchor and submitted. In the complete callbackesd_usb_read_bulk_callback(), the URBs are processed and resubmitted. Inesd_usb_close() the URBs are freed by callingusb_kill_anchored_urbs(&dev->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 esd_usb_close().Fix the memory leak by anchoring the URB in theesd_usb_read_bulk_callback() to the dev->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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: xen: scsiback: Fix potential memory leak in scsiback_remove()Memory allocated for struct vscsiblk_info in scsiback_probe() is notfreed in scsiback_remove() leading to potential memory leaks on remove,as well as in the scsiback_probe() error paths. Fix that by freeing itin scsiback_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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:intel_th: fix device leak on output open()Make sure to drop the reference taken when looking up the th deviceduring output device open() on errors and on close().Note that a recent commit fixed the leak in a couple of open() errorpaths but not all of them, and the reference is still leaking onsuccessful open().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: fix a race issue related to the operation on bpf_bound_progs listThe netdevsim driver lacks a protection mechanism for operations on thebpf_bound_progs list. When the nsim_bpf_create_prog() performslist_add_tail, it is possible that nsim_bpf_destroy_prog() issimultaneously performs list_del. Concurrent operations on the list maylead to list corruption and trigger a kernel crash as follows:[ 417.290971] kernel BUG at lib/list_debug.c:62![ 417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI[ 417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1[ 417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 417.291007] Workqueue: events bpf_prog_free_deferred[ 417.291021] RIP: 0010:__list_del_entry_valid_or_report+0xa7/0xc0[ 417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff <0f> 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8[ 417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246[ 417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000[ 417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180[ 417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003[ 417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20[ 417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000[ 417.291074] FS: 0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000[ 417.291079] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0[ 417.291088] PKRU: 55555554[ 417.291091] Call Trace:[ 417.291096] [ 417.291103] nsim_bpf_destroy_prog+0x31/0x80 [netdevsim][ 417.291154] __bpf_prog_offload_destroy+0x2a/0x80[ 417.291163] bpf_prog_dev_bound_destroy+0x6f/0xb0[ 417.291171] bpf_prog_free_deferred+0x18e/0x1a0[ 417.291178] process_one_work+0x18a/0x3a0[ 417.291188] worker_thread+0x27b/0x3a0[ 417.291197] ? __pfx_worker_thread+0x10/0x10[ 417.291207] kthread+0xe5/0x120[ 417.291214] ? __pfx_kthread+0x10/0x10[ 417.291221] ret_from_fork+0x31/0x50[ 417.291230] ? __pfx_kthread+0x10/0x10[ 417.291236] ret_from_fork_asm+0x1a/0x30[ 417.291246] Add a mutex lock, to prevent simultaneous addition and deletion operationson 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not strictly require dirty metadata threshold for metadata writepages[BUG]There is an internal report that over 1000 processes arewaiting at the io_schedule_timeout() of balance_dirty_pages(), causinga system hang and trigger a kernel coredump.The kernel is v6.4 kernel based, but the root problem still applies toany upstream kernel before v6.18.[CAUSE]From Jan Kara for his wisdom on the dirty page balance behavior first. This cgroup dirty limit was what was actually playing the role here because the cgroup had only a small amount of memory and so the dirty limit for it was something like 16MB. Dirty throttling is responsible for enforcing that nobody can dirty (significantly) more dirty memory than there's dirty limit. Thus when a task is dirtying pages it periodically enters into balance_dirty_pages() and we let it sleep there to slow down the dirtying. When the system is over dirty limit already (either globally or within a cgroup of the running task), we will not let the task exit from balance_dirty_pages() until the number of dirty pages drops below the limit. So in this particular case, as I already mentioned, there was a cgroup with relatively small amount of memory and as a result with dirty limit set at 16MB. A task from that cgroup has dirtied about 28MB worth of pages in btrfs btree inode and these were practically the only dirty pages in that cgroup.So that means the only way to reduce the dirty pages of that cgroup isto writeback the dirty pages of btrfs btree inode, and only after thatthose processes can exit balance_dirty_pages().Now back to the btrfs part, btree_writepages() is responsible forwriting back dirty btree inode pages.The problem here is, there is a btrfs internal threshold that if thebtree inode's dirty bytes are below the 32M threshold, it will notdo any writeback.This behavior is to batch as much metadata as possible so we won't writeback those tree blocks and then later re-COW them again for anothermodification.This internal 32MiB is higher than the existing dirty page size (28MiB),meaning no writeback will happen, causing a deadlock between btrfs andcgroup:- Btrfs doesn't want to write back btree inode until more dirty pages- Cgroup/MM doesn't want more dirty pages for btrfs btree inode Thus any process touching that btree inode is put into sleep until the number of dirty pages is reduced.Thanks Jan Kara a lot for the analysis of the root cause.[ENHANCEMENT]Since kernel commit b55102826d7d ("btrfs: set AS_KERNEL_FILE on thebtree_inode"), btrfs btree inode pages will only be charged to the rootcgroup which should have a much larger limit than btrfs' 32MiBthreshold.So it should not affect newer kernels.But for all current LTS kernels, they are all affected by this problem,and backporting the whole AS_KERNEL_FILE may not be a good idea.Even for newer kernels I still think it's a good idea to getrid of the internal threshold at btree_writepages(), since for most casescgroup/MM has a better view of full system memory usage than btrfs' fixedthreshold.For internal callers using btrfs_btree_balance_dirty() since thatfunction is already doing internal threshold check, we don't need tobother them.But for external callers of btree_writepages(), just respect theirrequests and write back whatever they want, ignoring the internalbtrfs threshold to avoid such deadlock on btree inode dirty pagebalancing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rocker: fix memory leak in rocker_world_port_post_fini()In rocker_world_port_pre_init(), rocker_port->wpriv is allocated withkzalloc(wops->port_priv_size, GFP_KERNEL). However, inrocker_world_port_post_fini(), the memory is only freed whenwops->port_post_fini callback is set: if (!wops->port_post_fini) return; wops->port_post_fini(rocker_port); kfree(rocker_port->wpriv);Since rocker_ofdpa_ops does not implement port_post_fini callback(it is NULL), the wpriv memory allocated for each port is never freedwhen ports are removed. This leads to a memory leak ofsizeof(struct ofdpa_port) bytes per port on every device removal.Fix this by always calling kfree(rocker_port->wpriv) regardless ofwhether the port_post_fini callback exists.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count()In iscsit_dec_conn_usage_count(), the function calls complete() whileholding the conn->conn_usage_lock. As soon as complete() is invoked, thewaiter (such as iscsit_close_connection()) may wake up and proceed to freethe iscsit_conn structure.If the waiter frees the memory before the current thread reachesspin_unlock_bh(), it results in a KASAN slab-use-after-free as the functionattempts to release a lock within the already-freed connection structure.Fix this by releasing the spinlock before calling 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: liquidio: Fix off-by-one error in VF setup_nic_devices() cleanupIn setup_nic_devices(), the initialization loop jumps to the labelsetup_nic_dev_free on failure. The current cleanup loop while(i--)skip the failing index i, causing a memory leak.Fix this by changing the loop to iterate from the current index idown to 0.Compile tested only. Issue found using 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: liquidio: Fix off-by-one error in PF setup_nic_devices() cleanupIn setup_nic_devices(), the initialization loop jumps to the labelsetup_nic_dev_free on failure. The current cleanup loop while(i--)skip the failing index i, causing a memory leak.Fix this by changing the loop to iterate from the current index idown to 0.Also, decrement i in the devlink_alloc failure path to point to thelast successfully allocated index.Compile tested only. Issue found using 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:IB/mthca: Add missed mthca_unmap_user_db() for mthca_create_srq()Fix a user triggerable leak on the system call failure 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: pn533: properly drop the usb interface reference on disconnectWhen the device is disconnected from the driver, there is a "dangling"reference count on the usb interface that was grabbed in the probecallback. Fix this up by properly dropping the reference after we aredone 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: annotate data-races around sk->sk_{data_ready,write_space}skmsg (and probably other layers) are changing these pointerswhile other cpus might read them concurrently.Add corresponding READ_ONCE()/WRITE_ONCE() annotationsfor UDP, TCP and AF_UNIX.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Don't log plaintext credentials in cifs_set_cifscredsWhen debug logging is enabled, cifs_set_cifscreds() logs the keypayload and exposes the plaintext username and password. Remove thedebug log to avoid exposing credentials.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: cancel rfkill_block work in wiphy_unregister()There is a use-after-free error in cfg80211_shutdown_all_interfaces foundby syzkaller:BUG: KASAN: use-after-free in cfg80211_shutdown_all_interfaces+0x213/0x220Read of size 8 at addr ffff888112a78d98 by task kworker/0:5/5326CPU: 0 UID: 0 PID: 5326 Comm: kworker/0:5 Not tainted 6.19.0-rc2 #2 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: events cfg80211_rfkill_block_workCall Trace: dump_stack_lvl+0x116/0x1f0 print_report+0xcd/0x630 kasan_report+0xe0/0x110 cfg80211_shutdown_all_interfaces+0x213/0x220 cfg80211_rfkill_block_work+0x1e/0x30 process_one_work+0x9cf/0x1b70 worker_thread+0x6c8/0xf10 kthread+0x3c5/0x780 ret_from_fork+0x56d/0x700 ret_from_fork_asm+0x1a/0x30 The problem arises due to the rfkill_block work is not cancelled when wiphyis being unregistered. In order to fix the issue cancel the correspondingwork in wiphy_unregister().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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blktrace: fix __this_cpu_read/write in preemptible contexttracing_record_cmdline() internally uses __this_cpu_read() and__this_cpu_write() on the per-CPU variable trace_cmdline_save, andtrace_save_cmdline() explicitly asserts preemption is disabled vialockdep_assert_preemption_disabled(). These operations are only safewhen preemption is off, as they were designed to be called from thescheduler context (probe_wakeup_sched_switch() / probe_wakeup()).__blk_add_trace() was calling tracing_record_cmdline(current) early inthe blk_tracer path, before ring buffer reservation, from processcontext where preemption is fully enabled. This triggers the followingusing blktests/blktrace/002:blktrace/002 (blktrace ftrace corruption with sysfs trace) [failed] runtime 0.367s ... 0.437s something found in dmesg: [ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [ 81.239580] null_blk: disk nullb1 created [ 81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516 [ 81.362842] caller is tracing_record_cmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] Tainted: [N]=TEST [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 81.362881] Call Trace: [ 81.362884] [ 81.362886] dump_stack_lvl+0x8d/0xb0 ... (See '/mnt/sda/blktests/results/nodev/blktrace/002.dmesg' for the entire message)[ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33[ 81.239580] null_blk: disk nullb1 created[ 81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516[ 81.362842] caller is tracing_record_cmdline+0x10/0x40[ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full)[ 81.362877] Tainted: [N]=TEST[ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014[ 81.362881] Call Trace:[ 81.362884] [ 81.362886] dump_stack_lvl+0x8d/0xb0[ 81.362895] check_preemption_disabled+0xce/0xe0[ 81.362902] tracing_record_cmdline+0x10/0x40[ 81.362923] __blk_add_trace+0x307/0x5d0[ 81.362934] ? lock_acquire+0xe0/0x300[ 81.362940] ? iov_iter_extract_pages+0x101/0xa30[ 81.362959] blk_add_trace_bio+0x106/0x1e0[ 81.362968] submit_bio_noacct_nocheck+0x24b/0x3a0[ 81.362979] ? lockdep_init_map_type+0x58/0x260[ 81.362988] submit_bio_wait+0x56/0x90[ 81.363009] __blkdev_direct_IO_simple+0x16c/0x250[ 81.363026] ? __pfx_submit_bio_wait_endio+0x10/0x10[ 81.363038] ? rcu_read_lock_any_held+0x73/0xa0[ 81.363051] blkdev_read_iter+0xc1/0x140[ 81.363059] vfs_read+0x20b/0x330[ 81.363083] ksys_read+0x67/0xe0[ 81.363090] do_syscall_64+0xbf/0xf00[ 81.363102] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 81.363106] RIP: 0033:0x7f281906029d[ 81.363111] Code: 31 c0 e9 c6 fe ff ff 50 48 8d 3d 66 63 0a 00 e8 59 ff 01 00 66 0f 1f 84 00 00 00 00 00 80 3d 41 33 0e 00 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec[ 81.363113] RSP: 002b:00007ffca127dd48 EFLAGS: 00000246 ORIG_RAX: 0000000000000000[ 81.363120] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f281906029d[ 81.363122] RDX: 0000000000001000 RSI: 0000559f8bfae000 RDI: 0000000000000000[ 81.363123] RBP: 0000000000001000 R08: 0000002863a10a81 R09: 00007f281915f000[ 81.363124] R10: 00007f2818f77b60 R11: 0000000000000246 R12: 0000559f8bfae000[ 81.363126] R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000a[ 81.363142] The same BUG fires from blk_add_trace_plug(), blk_add_trace_unplug(),and blk_add_trace_rq() paths as well.The purpose of tracin---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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Fix memory leak in ice_set_ringparam()In ice_set_ringparam, tx_rings and xdp_rings are allocated beforerx_rings. If the allocation of rx_rings fails, the code jumps tothe done label leaking both tx_rings and xdp_rings. Furthermore, ifthe setup of an individual Rx ring fails during the loop, the code jumpsto the free_tx label which releases tx_rings but leaks xdp_rings.Fix this by introducing a free_xdp label and updating the error paths toensure both xdp_rings and tx_rings are properly freed if rx_ringsallocation or setup fails.Compile tested only. Issue found using a prototype static analysis tooland 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_CT: drop pending enqueued packets on template removalTemplates refer to objects that can go away while packets are sitting innfqueue refer to:- helper, this can be an issue on module removal.- timeout policy, nfnetlink_cttimeout might remove it.The use of templates with zone and event cache filter are safe, sincethis just copies values.Flush these enqueued packets in case the template rule gets 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: replace recursive profile removal with iterative approachThe profile removal code uses recursion when removing nested profiles,which can lead to kernel stack exhaustion and system crashes.Reproducer: $ pf='a'; for ((i=0; i<1024; i++)); do echo -e "profile $pf { \n }" | apparmor_parser -K -a; pf="$pf//x"; done $ echo -n a > /sys/kernel/security/apparmor/.removeReplace the recursive __aa_profile_list_release() approach with aniterative approach in __remove_profile(). The function repeatedlyfinds and removes leaf profiles until the entire subtree is removed,maintaining the same removal semantic without recursion.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=nWhen CONFIG_IPV6 is disabled, the udp_sock_create6() function returns 0(success) without actually creating a socket. Callers such asfou_create() then proceed to dereference the uninitialized socketpointer, resulting in a NULL pointer dereference.The captured NULL deref crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764) [...] Call Trace: genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1)) __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1)) __x64_sys_sendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_64.S:130)This patch makes udp_sock_create6 return -EPFNOSUPPORT instead, socallers correctly take their error paths. There is only one caller ofthe vulnerable function and only privileged users can trigger 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: aqc111: Do not perform PM inside suspend callbacksyzbot reports "task hung in rpm_resume"This is caused by aqc111_suspend callingthe PM variant of its write_cmd routine.The simplified call trace looks like this:rpm_suspend() usb_suspend_both() - here udev->dev.power.runtime_status == RPM_SUSPENDING aqc111_suspend() - called for the usb device interface aqc111_write32_cmd() usb_autopm_get_interface() pm_runtime_resume_and_get() rpm_resume() - here we call rpm_resume() on our parent rpm_resume() - Here we wait for a status change that will never happen.At this point we block another task which holdsrtnl_lock and locks up the whole networking stack.Fix this by replacing the write_cmd calls with their _nopm variants
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Limit BO list entry count to prevent resource exhaustionUserspace can pass an arbitrary number of BO list entries via thebo_number field. Although the previous multiplication overflow checkprevents out-of-bounds allocation, a large number of entries could stillcause excessive memory allocation (up to potentially gigabytes) andunnecessarily long list processing times.Introduce a hard limit of 128k entries per BO list, which is more thansufficient for any realistic use case (e.g., a single list containing allbuffers in a large scene). This prevents memory exhaustion attacks andensures predictable performance.Return -EINVAL if the requested entry count exceeds the limit(cherry picked from commit 688b87d39e0aa8135105b40dc167d74b5ada5332)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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.52.1).
-
Description: Requests is a HTTP library. Prior to version 2.33.0, the `requests.utils.extract_zipped_paths()` utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one. Standard usage of the Requests library is not affected by this vulnerability. Only applications that call `extract_zipped_paths()` directly are impacted. Starting in version 2.33.0, the library extracts files to a non-deterministic location. If developers are unable to upgrade, they can set `TMPDIR` in their environment to a directory with restricted write access.
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.26.1).
-
Description: systemd, a system and service manager, (as PID 1) hits an assert and freezes execution when an unprivileged IPC API call is made with spurious data. On version v249 and older the effect is not an assert, but stack overwriting, with the attacker controlled content. From version v250 and newer this is not possible as the safety check causes an assert instead. This IPC call was added in v239, so versions older than that are not affected. Versions 260-rc1, 259.2, 258.5, and 257.11 contain patches. No known workarounds are available.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libsystemd0 > 0-0 (version in image is 228-157.75.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-net: fix OOB access in ULE extension header tablesThe ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[] tablesin handle_one_ule_extension() are declared with 255 elements (validindices 0-254), but the index htype is derived from network-controlleddata as (ule_sndu_type & 0x00FF), giving a range of 0-255. Whenhtype equals 255, an out-of-bounds read occurs on the function pointertable, and the OOB value may be called as a function pointer.Add a bounds check on htype against the array size before either tableis accessed. Out-of-range values now cause the SNDU to be discarded.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: atm: fix crash due to unvalidated vcc pointer in sigd_send()Reproducer available at [1].The ATM send path (sendmsg -> vcc_sendmsg -> sigd_send) reads the vccpointer from msg->vcc and uses it directly without any validation. Thispointer comes from userspace via sendmsg() and can be arbitrarily forged: int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // become ATM signaling daemon struct msghdr msg = { .msg_iov = &iov, ... }; *(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeefIn normal operation, the kernel sends the vcc pointer to the signalingdaemon via sigd_enq() when processing operations like connect(), bind(),or listen(). The daemon is expected to return the same pointer whenresponding. However, a malicious daemon can send arbitrary pointer values.Fix this by introducing find_get_vcc() which validates the pointer bysearching through vcc_hash (similar to how sigd_close() iterates overall VCCs), and acquires a reference via sock_hold() if found.Since struct atm_vcc embeds struct sock as its first member, they sharethe same lifetime. Therefore using sock_hold/sock_put is sufficient tokeep the vcc alive while it is being used.Note that there may be a race with sigd_close() which could mark the vccwith various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns.However, sock_hold() guarantees the memory remains valid, so this raceonly affects the logical state, not memory safety.[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_expect: use expect->helperUse expect->helper in ctnetlink and /proc to dump the helper name.Using nfct_help() without holding a reference to the master conntrackis unsafe.Use exp->master->helper in ctnetlink path if userspace does not providean explicit helper when creating an expectation to retain the existingbehaviour. The ctnetlink expectation path holds the reference on themaster conntrack and nf_conntrack_expect lock and the nfnetlink gluepath refers to the master ct that is attached to the 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: cls_fw: fix NULL pointer dereference on shared blocksThe old-method path in fw_classify() calls tcf_block_q() anddereferences q->handle. Shared blocks leave block->q NULL, causing aNULL deref when an empty cls_fw filter is attached to a shared blockand a packet with a nonzero major skb mark is classified.Reject the configuration in fw_change() when the old method (noTCA_OPTIONS) is used on a shared block, since fw_classify()'sold-method path needs block->q which is NULL for shared blocks.The fixed null-ptr-deref calling stack: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:fw_classify (net/sched/cls_fw.c:81) Call Trace: tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860) tc_run (net/core/dev.c:4401) __dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: cls_flow: fix NULL pointer dereference on shared blocksflow_change() calls tcf_block_q() and dereferences q->handle to derivea default baseclass. Shared blocks leave block->q NULL, causing a NULLderef when a flow filter without a fully qualified baseclass is createdon a shared block.Check tcf_block_shared() before accessing block->q and return -EINVALfor shared blocks. This avoids the null-deref shown below:=======================================================================KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]RIP: 0010:flow_change (net/sched/cls_flow.c:508)Call Trace: tc_new_tfilter (net/sched/cls_api.c:2432) rtnetlink_rcv_msg (net/core/rtnetlink.c:6980) [...]=======================================================================
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_hfsc: fix divide-by-zero in rtsc_min()m2sm() converts a u32 slope to a u64 scaled value. For large inputs(e.g. m1=4000000000), the result can reach 2^32. rtsc_min() storesthe difference of two such u64 values in a u32 variable `dsm` anduses it as a divisor. When the difference is exactly 2^32 thetruncation yields zero, causing a divide-by-zero oops in theconcave-curve intersection path: Oops: divide error: 0000 RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601) Call Trace: init_ed (net/sched/sch_hfsc.c:629) hfsc_enqueue (net/sched/sch_hfsc.c:1569) [...]Widen `dsm` to u64 and replace do_div() with div64_u64() so the fulldifference is preserved.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARPWeiming Shi says:xt_match and xt_target structs registered with NFPROTO_UNSPEC can beloaded by any protocol family through nft_compat. When such amatch/target sets .hooks to restrict which hooks it may run on, thebitmask uses NF_INET_* constants. This is only correct for familieswhose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridgeall share the same five hooks (PRE_ROUTING ... POST_ROUTING).ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with differentsemantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooksvalidation silently passes for the wrong reasons, allowing matches torun on ARP chains where the hook assumptions (e.g. state->in beingset on input hooks) do not hold. This leads to NULL pointerdereferences; xt_devgroup is one concrete example: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroup_mt+0xff/0x350 Call Trace: nft_match_eval (net/netfilter/nft_compat.c:407) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61) nf_hook_slow (net/netfilter/core.c:623) arp_xmit (net/ipv4/arp.c:666) Kernel panic - not syncing: Fatal exception in interruptFix it by restricting arptables to NFPROTO_ARP extensions only.Note that arptables-legacy only supports:- arpt_CLASSIFY- arpt_mangle- arpt_MARKthat provide explicit NFPROTO_ARP match/target declarations.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rds: ib: reject FRMR registration before IB connection is establishedrds_ib_get_mr() extracts the rds_ib_connection from conn->c_transport_dataand passes it to rds_ib_reg_frmr() for FRWR memory registration. On afresh outgoing connection, ic is allocated in rds_ib_conn_alloc() withi_cm_id = NULL because the connection worker has not yet calledrds_ib_conn_path_connect() to create the rdma_cm_id. When sendmsg() withRDS_CMSG_RDMA_MAP is called on such a connection, the sendmsg path parsesthe control message before any connection establishment, allowingrds_ib_post_reg_frmr() to dereference ic->i_cm_id->qp and crash thekernel.The existing guard in rds_ib_reg_frmr() only checks for !ic (added incommit 9e630bcb7701), which does not catch this case since ic is allocatedearly and is always non-NULL once the connection object exists. KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rds_ib_post_reg_frmr+0x50e/0x920 Call Trace: rds_ib_post_reg_frmr (net/rds/ib_frmr.c:167) rds_ib_map_frmr (net/rds/ib_frmr.c:252) rds_ib_reg_frmr (net/rds/ib_frmr.c:430) rds_ib_get_mr (net/rds/ib_rdma.c:615) __rds_rdma_map (net/rds/rdma.c:295) rds_cmsg_rdma_map (net/rds/rdma.c:860) rds_sendmsg (net/rds/send.c:1363) ____sys_sendmsg do_syscall_64Add a check in rds_ib_get_mr() that verifies ic, i_cm_id, and qp are allnon-NULL before proceeding with FRMR registration, mirroring the guardalready present in rds_ib_post_inv(). Return -ENODEV when the connectionis not ready, which the existing error handling in rds_cmsg_send() convertsto -EAGAIN for userspace retry and triggers rds_conn_connect_if_down() tostart the connection worker.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD__build_packet_message() manually constructs the NFULA_PAYLOAD netlinkattribute using skb_put() and skb_copy_bits(), bypassing the standardnla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytesare allocated (including NLA alignment padding), only data_len bytesof actual packet data are copied. The trailing nla_padlen(data_len)bytes (1-3 when data_len is not 4-byte aligned) are never initialized,leaking stale heap contents to userspace via the NFLOG netlink socket.Replace the manual attribute construction with nla_reserve(), whichhandles the tailroom check, header setup, and padding zeroing via__nla_reserve(). The subsequent skb_copy_bits() fills in the payloaddata on top of the properly initialized attribute.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: reject mount if bigalloc with s_first_data_block != 0bigalloc with s_first_data_block != 0 is not supported, reject mountingit.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: validate p_idx bounds in ext4_ext_correct_indexesext4_ext_correct_indexes() walks up the extent tree correctingindex entries when the first extent in a leaf is modified. Beforeaccessing path[k].p_idx->ei_block, there is no validation thatp_idx falls within the valid range of index entries for thatlevel.If the on-disk extent header contains a corrupted or craftedeh_entries value, p_idx can point past the end of the allocatedbuffer, causing a slab-out-of-bounds read.Fix this by validating path[k].p_idx against EXT_LAST_INDEX() atboth access sites: before the while loop and inside it. Return-EFSCORRUPTED if the index pointer is out of range, consistentwith how other bounds violations are handled in the ext4 extenttree 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: publish jinode after initializationext4_inode_attach_jinode() publishes ei->jinode to concurrent users.It used to set ei->jinode before jbd2_journal_init_jbd_inode(),allowing a reader to observe a non-NULL jinode with i_vfs_inodestill unset.The fast commit flush path can then pass this jinode tojbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping andmay crash.Below is the crash I observe:```BUG: unable to handle page fault for address: 000000010beb47f4PGD 110e51067 P4D 110e51067 PUD 0Oops: Oops: 0000 [#1] SMP NOPTICPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014RIP: 0010:xas_find_marked+0x3d/0x2e0Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ecR10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0PKRU: 55555554Call Trace:filemap_get_folios_tag+0x87/0x2a0__filemap_fdatawait_range+0x5f/0xd0? srso_alias_return_thunk+0x5/0xfbef5? __schedule+0x3e7/0x10c0? srso_alias_return_thunk+0x5/0xfbef5? srso_alias_return_thunk+0x5/0xfbef5? srso_alias_return_thunk+0x5/0xfbef5? preempt_count_sub+0x5f/0x80? srso_alias_return_thunk+0x5/0xfbef5? cap_safe_nice+0x37/0x70? srso_alias_return_thunk+0x5/0xfbef5? preempt_count_sub+0x5f/0x80? srso_alias_return_thunk+0x5/0xfbef5filemap_fdatawait_range_keep_errors+0x12/0x40ext4_fc_commit+0x697/0x8b0? ext4_file_write_iter+0x64b/0x950? srso_alias_return_thunk+0x5/0xfbef5? preempt_count_sub+0x5f/0x80? srso_alias_return_thunk+0x5/0xfbef5? vfs_write+0x356/0x480? srso_alias_return_thunk+0x5/0xfbef5? preempt_count_sub+0x5f/0x80ext4_sync_file+0xf7/0x370do_fsync+0x3b/0x80? syscall_trace_enter+0x108/0x1d0__x64_sys_fdatasync+0x16/0x20do_syscall_64+0x62/0x2c0entry_SYSCALL_64_after_hwframe+0x76/0x7e...```Fix this by initializing the jbd2_inode first.Use smp_wmb() and WRITE_ONCE() to publish ei->jinode afterinitialization. Readers use READ_ONCE() to fetch the pointer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: prevent immediate PASID reuse casePASID resue could cause interrupt issue when processimmediately runs into hw state left by previousprocess exited with the same PASID, it's possible thatpage faults are still pending in the IH ring buffer whenthe process exits and frees up its PASID. To prevent thecase, it uses idr cyclic allocator same as kernel pid's.(cherry picked from commit 8f1de51f49be692de137c8525106e0fce2d1912d)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (pmbus/core) Protect regulator operations with mutexThe regulator operations pmbus_regulator_get_voltage(),pmbus_regulator_set_voltage(), and pmbus_regulator_list_voltage()access PMBus registers and shared data but were not protected bythe update_lock mutex. This could lead to race conditions.However, adding mutex protection directly to these functions causesa deadlock because pmbus_regulator_notify() (which callsregulator_notifier_call_chain()) is often called with the mutexalready held (e.g., from pmbus_fault_handler()). If a regulatorcallback then calls one of the now-protected voltage functions,it will attempt to acquire the same mutex.Rework pmbus_regulator_notify() to utilize a worker function tosend notifications outside of the mutex protection. Events arestored as atomics in a per-page bitmask and processed by the worker.Initialize the worker and its associated data during regulatorregistration, and ensure it is cancelled on device removal usingdevm_add_action_or_reset().While at it, remove the unnecessary include of linux/of.h.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: use netlink policy range checksReplace manual range and mask validations with netlink policyannotations in ctnetlink code paths, so that the netlink core rejectsinvalid values early and can generate extack errors.- CTA_PROTOINFO_TCP_STATE: reject values > TCP_CONNTRACK_SYN_SENT2 at policy level, removing the manual >= TCP_CONNTRACK_MAX check.- CTA_PROTOINFO_TCP_WSCALE_ORIGINAL/REPLY: reject values > TCP_MAX_WSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count.- CTA_FILTER_ORIG_FLAGS/REPLY_FLAGS: use NLA_POLICY_MASK with CTA_FILTER_F_ALL, removing the manual mask checks.- CTA_EXPECT_FLAGS: use NLA_POLICY_MASK with NF_CT_EXPECT_MASK, adding a new mask define grouping all valid expect flags.Extracted from a broader nf-next patch by Florian Westphal, scoped toctnetlink for the fixes tree.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: clamp SCO altsetting table indicesbtusb_work() maps the number of active SCO links to USB alternatesettings through a three-entry lookup table when CVSD traffic usestransparent voice settings. The lookup currently indexes alts[] withdata->sco_num - 1 without first constraining sco_num to the number ofavailable table entries.While the table only defines alternate settings for up to three SCOlinks, data->sco_num comes from hci_conn_num() and is used directly.Cap the lookup to the last table entry before indexing it so thedriver keeps selecting the highest supported alternate setting withoutreading past alts[].
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cbBefore using sk pointer, check if it is null.Fix the following: KASAN: null-ptr-deref in range [0x0000000000000260-0x0000000000000267] CPU: 0 UID: 0 PID: 5985 Comm: kworker/0:5 Not tainted 7.0.0-rc4-00029-ga989fde763f4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-9.fc43 06/10/2025 Workqueue: events l2cap_info_timeout RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce veth0_macvtap: entered promiscuous mode RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005582615a5008 CR3: 000000007007e000 CR4: 0000000000752ef0 PKRU: 55555554 Call Trace: __kasan_check_byte+0x12/0x40 lock_acquire+0x79/0x2e0 lock_sock_nested+0x48/0x100 ? l2cap_sock_ready_cb+0x46/0x160 l2cap_sock_ready_cb+0x46/0x160 l2cap_conn_start+0x779/0xff0 ? __pfx_l2cap_conn_start+0x10/0x10 ? l2cap_info_timeout+0x60/0xa0 ? __pfx___mutex_lock+0x10/0x10 l2cap_info_timeout+0x68/0xa0 ? process_scheduled_works+0xa8d/0x18c0 process_scheduled_works+0xb6e/0x18c0 ? __pfx_process_scheduled_works+0x10/0x10 ? assign_work+0x3d5/0x5e0 worker_thread+0xa53/0xfc0 kthread+0x388/0x470 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x51e/0xb90 ? __pfx_ret_from_fork+0x10/0x10 veth1_macvtap: entered promiscuous mode ? __switch_to+0xc7d/0x1450 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- batman_adv: batadv0: Interface activated: batadv_slave_0 batman_adv: batadv0: Interface activated: batadv_slave_1 netdevsim netdevsim7 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce ieee80211 phy39: Selected rate control algorithm 'minstrel_ht' RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e16139e9c CR3: 000000000e74e000 CR4: 0000000000752ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: set BTRFS_ROOT_ORPHAN_CLEANUP during subvol createWe have recently observed a number of subvolumes with broken dentries.ls-ing the parent dir looks like:drwxrwxrwt 1 root root 16 Jan 23 16:49 .drwxr-xr-x 1 root root 24 Jan 23 16:48 ..d????????? ? ? ? ? ? broken_subvoland similarly stat-ing the file fails.In this state, deleting the subvol fails with ENOENT, but attempting tocreate a new file or subvol over it errors out with EEXIST and evenaborts the fs. Which leaves us a bit stuck.dmesg contains a single notable error message reading:"could not do orphan cleanup -2"2 is ENOENT and the error comes from the failure handling path ofbtrfs_orphan_cleanup(), with the stack leading back up tobtrfs_lookup().btrfs_lookupbtrfs_lookup_dentrybtrfs_orphan_cleanup // prints that message and returns -ENOENTAfter some detailed inspection of the internal state, it became clearthat:- there are no orphan items for the subvol- the subvol is otherwise healthy looking, it is not half-deleted or anything, there is no drop progress, etc.- the subvol was created a while ago and does the meaningful first btrfs_orphan_cleanup() call that sets BTRFS_ROOT_ORPHAN_CLEANUP much later.- after btrfs_orphan_cleanup() fails, btrfs_lookup_dentry() returns -ENOENT, which results in a negative dentry for the subvolume via d_splice_alias(NULL, dentry), leading to the observed behavior. The bug can be mitigated by dropping the dentry cache, at which point we can successfully delete the subvolume if we want.i.e.,btrfs_lookup() btrfs_lookup_dentry() if (!sb_rdonly(inode->vfs_inode)->vfs_inode) btrfs_orphan_cleanup(sub_root) test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP) btrfs_search_slot() // finds orphan item for inode N ... prints "could not do orphan cleanup -2" if (inode == ERR_PTR(-ENOENT)) inode = NULL; return d_splice_alias(NULL, dentry) // NEGATIVE DENTRY for valid subvolumebtrfs_orphan_cleanup() does test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP)on the root when it runs, so it cannot run more than once on a givenroot, so something else must run concurrently. However, the obviousroutes to deleting an orphan when nlinks goes to 0 should not be able torun without first doing a lookup into the subvolume, which should runbtrfs_orphan_cleanup() and set the bit.The final important observation is that create_subvol() callsd_instantiate_new() but does not set BTRFS_ROOT_ORPHAN_CLEANUP, so ifthe dentry cache gets dropped, the next lookup into the subvolume willmake a real call into btrfs_orphan_cleanup() for the first time. Thisopens up the possibility of concurrently deleting the inode/orphan itemsbut most typical evict() paths will be holding a reference on the parentdentry (child dentry holds parent->d_lockref.count via dget ind_alloc(), released in __dentry_kill()) and prevent the parent frombeing removed from the dentry cache.The one exception is delayed iputs. Ordered extent creation callsigrab() on the inode. If the file is unlinked and closed while thoserefs are held, iput() in __dentry_kill() decrements i_count but doesnot trigger eviction (i_count > 0). The child dentry is freed and thesubvol dentry's d_lockref.count drops to 0, making it evictable whilethe inode is still alive.Since there are two races (the race between writeback and unlink andthe race between lookup and delayed iputs), and there are too many movingparts, the following three diagrams show the complete picture.(Only the second and third are races)Phase 1:Create Subvol in dentry cache without BTRFS_ROOT_ORPHAN_CLEANUP setbtrfs_mksubvol() lookup_one_len() __lookup_slow() d_alloc_parallel() __d_alloc() // d_lockref.count = 1 create_subvol(dentry) // doesn't touch the bit.. d_instantiate_new(dentry, inode) // dentry in cache with d_lockref.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gt: Check set_default_submission() before deferencingWhen the i915 driver firmware binaries are not present, theset_default_submission pointer is not set. This pointer isdereferenced during suspend anyways.Add a check to make sure it is set before dereferencing.[ 23.289926] PM: suspend entry (deep)[ 23.293558] Filesystems sync: 0.000 seconds[ 23.298010] Freezing user space processes[ 23.302771] Freezing user space processes completed (elapsed 0.000 seconds)[ 23.309766] OOM killer disabled.[ 23.313027] Freezing remaining freezable tasks[ 23.318540] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)[ 23.342038] serial 00:05: disabled[ 23.345719] serial 00:02: disabled[ 23.349342] serial 00:01: disabled[ 23.353782] sd 0:0:0:0: [sda] Synchronizing SCSI cache[ 23.358993] sd 1:0:0:0: [sdb] Synchronizing SCSI cache[ 23.361635] ata1.00: Entering standby power mode[ 23.368863] ata2.00: Entering standby power mode[ 23.445187] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 23.452194] #PF: supervisor instruction fetch in kernel mode[ 23.457896] #PF: error_code(0x0010) - not-present page[ 23.463065] PGD 0 P4D 0[ 23.465640] Oops: Oops: 0010 [#1] SMP NOPTI[ 23.469869] CPU: 8 UID: 0 PID: 211 Comm: kworker/u48:18 Tainted: G S W 6.19.0-rc4-00020-gf0b9d8eb98df #10 PREEMPT(voluntary)[ 23.482512] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN[ 23.496511] Workqueue: async async_run_entry_fn[ 23.501087] RIP: 0010:0x0[ 23.503755] Code: Unable to access opcode bytes at 0xffffffffffffffd6.[ 23.510324] RSP: 0018:ffffb4a60065fca8 EFLAGS: 00010246[ 23.515592] RAX: 0000000000000000 RBX: ffff9f428290e000 RCX: 000000000000000f[ 23.522765] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff9f428290e000[ 23.529937] RBP: ffff9f4282907070 R08: ffff9f4281130428 R09: 00000000ffffffff[ 23.537111] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9f42829070f8[ 23.544284] R13: ffff9f4282906028 R14: ffff9f4282900000 R15: ffff9f4282906b68[ 23.551457] FS: 0000000000000000(0000) GS:ffff9f466b2cf000(0000) knlGS:0000000000000000[ 23.559588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 23.565365] CR2: ffffffffffffffd6 CR3: 000000031c230001 CR4: 0000000000f70ef0[ 23.572539] PKRU: 55555554[ 23.575281] Call Trace:[ 23.577770] [ 23.579905] intel_engines_reset_default_submission+0x42/0x60[ 23.585695] __intel_gt_unset_wedged+0x191/0x200[ 23.590360] intel_gt_unset_wedged+0x20/0x40[ 23.594675] gt_sanitize+0x15e/0x170[ 23.598290] i915_gem_suspend_late+0x6b/0x180[ 23.602692] i915_drm_suspend_late+0x35/0xf0[ 23.607008] ? __pfx_pci_pm_suspend_late+0x10/0x10[ 23.611843] dpm_run_callback+0x78/0x1c0[ 23.615817] device_suspend_late+0xde/0x2e0[ 23.620037] async_suspend_late+0x18/0x30[ 23.624082] async_run_entry_fn+0x25/0xa0[ 23.628129] process_one_work+0x15b/0x380[ 23.632182] worker_thread+0x2a5/0x3c0[ 23.635973] ? __pfx_worker_thread+0x10/0x10[ 23.640279] kthread+0xf6/0x1f0[ 23.643464] ? __pfx_kthread+0x10/0x10[ 23.647263] ? __pfx_kthread+0x10/0x10[ 23.651045] ret_from_fork+0x131/0x190[ 23.654837] ? __pfx_kthread+0x10/0x10[ 23.658634] ret_from_fork_asm+0x1a/0x30[ 23.662597] [ 23.664826] Modules linked in:[ 23.667914] CR2: 0000000000000000[ 23.671271] ------------[ cut here ]------------(cherry picked from commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bonding: fix NULL deref in bond_debug_rlb_hash_showrlb_clear_slave intentionally keeps RLB hash-table entries onthe rx_hashtbl_used_head list with slave set to NULL when noreplacement slave is available. However, bond_debug_rlb_hash_showvisites client_info->slave without checking if it's NULL.Other used-list iterators in bond_alb.c already handle this NULL-slavestate safely:- rlb_update_client returns early on !client_info->slave- rlb_req_update_slave_clients, rlb_clear_slave, and rlb_rebalancecompare slave values before visiting- lb_req_update_subnet_clients continues if slave is NULLThe following NULL deref crash can be trigger inbond_debug_rlb_hash_show:[ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 1.292058] RIP: 0010:bond_debug_rlb_hash_show (drivers/net/bonding/bond_debugfs.c:41)[ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286[ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204[ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078[ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000[ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0[ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8[ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000[ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0[ 1.295897] Call Trace:[ 1.296134] seq_read_iter (fs/seq_file.c:231)[ 1.296341] seq_read (fs/seq_file.c:164)[ 1.296493] full_proxy_read (fs/debugfs/file.c:378 (discriminator 1))[ 1.296658] vfs_read (fs/read_write.c:572)[ 1.296981] ksys_read (fs/read_write.c:717)[ 1.297132] do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))[ 1.297325] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)Add a NULL check and print "(none)" for entries with no assigned slave.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: hackrf: fix to not free memory after the device is registered in hackrf_probe()In hackrf driver, the following race condition occurs:``` CPU0 CPU1hackrf_probe() kzalloc(); // alloc hackrf_dev .... v4l2_device_register(); .... fd = sys_open("/path/to/dev"); // open hackrf fd .... v4l2_device_unregister(); .... kfree(); // free hackrf_dev .... sys_ioctl(fd, ...); v4l2_ioctl(); video_is_registered() // UAF!! .... sys_close(fd); v4l2_release() // UAF!! hackrf_video_release() kfree(); // DFB!!```When a V4L2 or video device is unregistered, the device node is removed sonew open() calls are blocked.However, file descriptors that are already open-and any in-flight I/O-donot terminate immediately; they remain valid until the last reference isdropped and the driver's release() is invoked.Therefore, freeing device memory on the error path after hackrf_probe()has registered dev it will lead to a race to use-after-free vuln, sincethose already-open handles haven't been released yet.And since release() free memory too, race to use-after-free anddouble-free vuln occur.To prevent this, if device is registered from probe(), it should bemodified to free memory only through release() rather than callingkfree() directly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: as102: fix to not free memory after the device is registered in as102_usb_probe()In as102_usb driver, the following race condition occurs:``` CPU0 CPU1as102_usb_probe() kzalloc(); // alloc as102_dev_t .... usb_register_dev(); fd = sys_open("/path/to/dev"); // open as102 fd .... usb_deregister_dev(); .... kfree(); // free as102_dev_t .... sys_close(fd); as102_release() // UAF!! as102_usb_release() kfree(); // DFB!!```When a USB character device registered with usb_register_dev() is laterunregistered (via usb_deregister_dev() or disconnect), the device node isremoved so new open() calls fail. However, file descriptors that arealready open do not go away immediately: they remain valid until the lastreference is dropped and the driver's .release() is invoked.In as102, as102_usb_probe() calls usb_register_dev() and then, on anerror path, does usb_deregister_dev() and frees as102_dev_t right away.If userspace raced a successful open() before the deregistration, thatopen FD will later hit as102_release() --> as102_usb_release() and accessor free as102_dev_t again, occur a race to use-after-free anddouble-free vuln.The fix is to never kfree(as102_dev_t) directly once usb_register_dev()has succeeded. After deregistration, defer freeing memory to .release().In other words, let release() perform the last kfree when the final openFD is closed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGIONDrop the WARN in sev_pin_memory() on npages overflowing an int, as theWARN is comically trivially to trigger from userspace, e.g. by doing: struct kvm_enc_region range = { .addr = 0, .size = -1ul, }; __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range);Note, the checks in sev_mem_enc_register_region() that presumably exist toverify the incoming address+size are completely worthless, as both "addr"and "size" are u64s and SEV is 64-bit only, i.e. they _can't_ be greaterthan ULONG_MAX. That wart will be cleaned up in the near future. if (range->addr > ULONG_MAX || range->size > ULONG_MAX) return -EINVAL;Opportunistically add a comment to explain why the code calculates thenumber of pages the "hard" way, e.g. instead of just shifting @ulen.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SEV: Protect *all* of sev_mem_enc_register_region() with kvm->lockTake and hold kvm->lock for before checking sev_guest() insev_mem_enc_register_region(), as sev_guest() isn't stable unless kvm->lockis held (or KVM can guarantee KVM_SEV_INIT{2} has completed and can'trollack state). If KVM_SEV_INIT{2} fails, KVM can end up trying to add toa not-yet-initialized sev->regions_list, e.g. triggering a #GP Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 110 UID: 0 PID: 72717 Comm: syz.15.11462 Tainted: G U W O 6.16.0-smp-DEV #1 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024 RIP: 0010:sev_mem_enc_register_region+0x3f0/0x4f0 ../include/linux/list.h:83 Code: <41> 80 3c 04 00 74 08 4c 89 ff e8 f1 c7 a2 00 49 39 ed 0f 84 c6 00 RSP: 0018:ffff88838647fbb8 EFLAGS: 00010256 RAX: dffffc0000000000 RBX: 1ffff92015cf1e0b RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000001000 RDI: ffff888367870000 RBP: ffffc900ae78f050 R08: ffffea000d9e0007 R09: 1ffffd4001b3c000 R10: dffffc0000000000 R11: fffff94001b3c001 R12: 0000000000000000 R13: ffff8982ab0bde00 R14: ffffc900ae78f058 R15: 0000000000000000 FS: 00007f34e9dc66c0(0000) GS:ffff89ee64d33000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe180adef98 CR3: 000000047210e000 CR4: 0000000000350ef0 Call Trace: kvm_arch_vm_ioctl+0xa72/0x1240 ../arch/x86/kvm/x86.c:7371 kvm_vm_ioctl+0x649/0x990 ../virt/kvm/kvm_main.c:5363 __se_sys_ioctl+0x101/0x170 ../fs/ioctl.c:51 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x6f/0x1f0 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f34e9f7e9a9 Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f34e9dc6038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f34ea1a6080 RCX: 00007f34e9f7e9a9 RDX: 0000200000000280 RSI: 000000008010aebb RDI: 0000000000000007 RBP: 00007f34ea000d69 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f34ea1a6080 R15: 00007ffce77197a8 with a syzlang reproducer that looks like: syz_kvm_add_vcpu$x86(0x0, &(0x7f0000000040)={0x0, &(0x7f0000000180)=ANY=[], 0x70}) (async) syz_kvm_add_vcpu$x86(0x0, &(0x7f0000000080)={0x0, &(0x7f0000000180)=ANY=[@ANYBLOB="..."], 0x4f}) (async) r0 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000200), 0x0, 0x0) r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0) r2 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000240), 0x0, 0x0) r3 = ioctl$KVM_CREATE_VM(r2, 0xae01, 0x0) ioctl$KVM_SET_CLOCK(r3, 0xc008aeba, &(0x7f0000000040)={0x1, 0x8, 0x0, 0x5625e9b0}) (async) ioctl$KVM_SET_PIT2(r3, 0x8010aebb, &(0x7f0000000280)={[...], 0x5}) (async) ioctl$KVM_SET_PIT2(r1, 0x4070aea0, 0x0) (async) r4 = ioctl$KVM_CREATE_VM(0xffffffffffffffff, 0xae01, 0x0) openat$kvm(0xffffffffffffff9c, 0x0, 0x0, 0x0) (async) ioctl$KVM_SET_USER_MEMORY_REGION(r4, 0x4020ae46, &(0x7f0000000400)={0x0, 0x0, 0x0, 0x2000, &(0x7f0000001000/0x2000)=nil}) (async) r5 = ioctl$KVM_CREATE_VCPU(r4, 0xae41, 0x2) close(r0) (async) openat$kvm(0xffffffffffffff9c, &(0x7f0000000000), 0x8000, 0x0) (async) ioctl$KVM_SET_GUEST_DEBUG(r5, 0x4048ae9b, &(0x7f0000000300)={0x4376ea830d46549b, 0x0, [0x46, 0x0, 0x0, 0x0, 0x0, 0x1000]}) (async) ioctl$KVM_RUN(r5, 0xae80, 0x0)Opportunistically use guard() to avoid having to define a new error labeland goto usage.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: handle invalid dinode in ocfs2_group_extend[BUG]kernel BUG at fs/ocfs2/resize.c:308!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTIRIP: 0010:ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c:308Code: 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1feCall Trace: ... ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e ...[CAUSE]ocfs2_group_extend() assumes that the global bitmap inode blockreturned from ocfs2_inode_lock() has already been validated andBUG_ONs when the signature is not a dinode. That assumption is toostrong for crafted filesystems because the JBD2-managed buffer pathcan bypass structural validation and return an invalid dinode to theresize ioctl.[FIX]Validate the dinode explicitly in ocfs2_group_extend(). If the globalbitmap buffer does not contain a valid dinode, report filesystemcorruption with ocfs2_error() and fail the resize operation instead ofcrashing 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: mm: Handle invalid large leaf mappings correctlyIt has been possible for a long time to mark ptes in the linear map asinvalid. This is done for secretmem, kfence, realm dma memory un/share,and others, by simply clearing the PTE_VALID bit. But until commita166563e7ec37 ("arm64: mm: support large block mapping whenrodata=full") large leaf mappings were never made invalid in this way.It turns out various parts of the code base are not equipped to handleinvalid large leaf mappings (in the way they are currently encoded) andI've observed a kernel panic while booting a realm guest on aBBML2_NOABORT system as a result:[ 15.432706] software IO TLB: Memory encryption is active and system is using DMA bounce buffers[ 15.476896] Unable to handle kernel paging request at virtual address ffff000019600000[ 15.513762] Mem abort info:[ 15.527245] ESR = 0x0000000096000046[ 15.548553] EC = 0x25: DABT (current EL), IL = 32 bits[ 15.572146] SET = 0, FnV = 0[ 15.592141] EA = 0, S1PTW = 0[ 15.612694] FSC = 0x06: level 2 translation fault[ 15.640644] Data abort info:[ 15.661983] ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000[ 15.694875] CM = 0, WnR = 1, TnD = 0, TagAccess = 0[ 15.723740] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 15.755776] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000081f3f000[ 15.800410] [ffff000019600000] pgd=0000000000000000, p4d=180000009ffff403, pud=180000009fffe403, pmd=00e8000199600704[ 15.855046] Internal error: Oops: 0000000096000046 [#1] SMP[ 15.886394] Modules linked in:[ 15.900029] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc4-dirty #4 PREEMPT[ 15.935258] Hardware name: linux,dummy-virt (DT)[ 15.955612] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)[ 15.986009] pc : __pi_memcpy_generic+0x128/0x22c[ 16.006163] lr : swiotlb_bounce+0xf4/0x158[ 16.024145] sp : ffff80008000b8f0[ 16.038896] x29: ffff80008000b8f0 x28: 0000000000000000 x27: 0000000000000000[ 16.069953] x26: ffffb3976d261ba8 x25: 0000000000000000 x24: ffff000019600000[ 16.100876] x23: 0000000000000001 x22: ffff0000043430d0 x21: 0000000000007ff0[ 16.131946] x20: 0000000084570010 x19: 0000000000000000 x18: ffff00001ffe3fcc[ 16.163073] x17: 0000000000000000 x16: 00000000003fffff x15: 646e612065766974[ 16.194131] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000[ 16.225059] x11: 0000000000000000 x10: 0000000000000010 x9 : 0000000000000018[ 16.256113] x8 : 0000000000000018 x7 : 0000000000000000 x6 : 0000000000000000[ 16.287203] x5 : ffff000019607ff0 x4 : ffff000004578000 x3 : ffff000019600000[ 16.318145] x2 : 0000000000007ff0 x1 : ffff000004570010 x0 : ffff000019600000[ 16.349071] Call trace:[ 16.360143] __pi_memcpy_generic+0x128/0x22c (P)[ 16.380310] swiotlb_tbl_map_single+0x154/0x2b4[ 16.400282] swiotlb_map+0x5c/0x228[ 16.415984] dma_map_phys+0x244/0x2b8[ 16.432199] dma_map_page_attrs+0x44/0x58[ 16.449782] virtqueue_map_page_attrs+0x38/0x44[ 16.469596] virtqueue_map_single_attrs+0xc0/0x130[ 16.490509] virtnet_rq_alloc.isra.0+0xa4/0x1fc[ 16.510355] try_fill_recv+0x2a4/0x584[ 16.526989] virtnet_open+0xd4/0x238[ 16.542775] __dev_open+0x110/0x24c[ 16.558280] __dev_change_flags+0x194/0x20c[ 16.576879] netif_change_flags+0x24/0x6c[ 16.594489] dev_change_flags+0x48/0x7c[ 16.611462] ip_auto_config+0x258/0x1114[ 16.628727] do_one_initcall+0x80/0x1c8[ 16.645590] kernel_init_freeable+0x208/0x2f0[ 16.664917] kernel_init+0x24/0x1e0[ 16.680295] ret_from_fork+0x10/0x20[ 16.696369] Code: 927cec03 cb0e0021 8b0e0042 a9411c26 (a900340c)[ 16.723106] ---[ end trace 0000000000000000 ]---[ 16.752866] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b[ 16.792556] Kernel Offset: 0x3396ea200000 from 0xffff8000800000---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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/xe: Reorganize the init to decouple migration from resetAttempting to issue reset on VF devices that don't support migrationleads to the following: BUG: unable to handle page fault for address: 00000000000011f8 #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: 2 UID: 0 PID: 7443 Comm: xe_sriov_flr Tainted: G S U 7.0.0-rc1-lgci-xe-xe-4588-cec43d5c2696af219-nodebug+ #1 PREEMPT(lazy) Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 RIP: 0010:xe_sriov_vfio_wait_flr_done+0xc/0x80 [xe] Code: ff c3 cc cc cc cc 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 54 53 <83> bf f8 11 00 00 02 75 61 41 89 f4 85 f6 74 52 48 8b 47 08 48 89 RSP: 0018:ffffc9000f7c39b8 EFLAGS: 00010202 RAX: ffffffffa04d8660 RBX: ffff88813e3e4000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000f7c39c8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff888101a48800 R13: ffff88813e3e4150 R14: ffff888130d0d008 R15: ffff88813e3e40d0 FS: 00007877d3d0d940(0000) GS:ffff88890b6d3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000011f8 CR3: 000000015a762000 CR4: 0000000000f52ef0 PKRU: 55555554 Call Trace: xe_vfio_pci_reset_done+0x49/0x120 [xe_vfio_pci] pci_dev_restore+0x3b/0x80 pci_reset_function+0x109/0x140 reset_store+0x5c/0xb0 dev_attr_store+0x17/0x40 sysfs_kf_write+0x72/0x90 kernfs_fop_write_iter+0x161/0x1f0 vfs_write+0x261/0x440 ksys_write+0x69/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x259/0x26e0 do_syscall_64+0xcb/0x1500 ? __fput+0x1a2/0x2d0 ? fput_close_sync+0x3d/0xa0 ? __x64_sys_close+0x3e/0x90 ? x64_sys_call+0x1b7c/0x26e0 ? do_syscall_64+0x109/0x1500 ? __task_pid_nr_ns+0x68/0x100 ? __do_sys_getpid+0x1d/0x30 ? x64_sys_call+0x10b5/0x26e0 ? do_syscall_64+0x109/0x1500 ? putname+0x41/0x90 ? do_faccessat+0x1e8/0x300 ? __x64_sys_access+0x1c/0x30 ? x64_sys_call+0x1822/0x26e0 ? do_syscall_64+0x109/0x1500 ? tick_program_event+0x43/0xa0 ? hrtimer_interrupt+0x126/0x260 ? irqentry_exit+0xb2/0x710 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7877d5f1c5a4 Code: 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 a5 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 89 RSP: 002b:00007fff48e5f908 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007877d5f1c5a4 RDX: 0000000000000001 RSI: 00007877d621b0c9 RDI: 0000000000000009 RBP: 0000000000000001 R08: 00005fb49113b010 R09: 0000000000000007 R10: 0000000000000000 R11: 0000000000000202 R12: 00007877d621b0c9 R13: 0000000000000009 R14: 00007fff48e5fac0 R15: 00007fff48e5fac0 This is caused by the fact that some of the xe_vfio_pci_core_devicemembers needed for handling reset are only initialized as part ofmigration init.Fix the problem by reorganizing the code to decouple VF init frommigration 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFOMuch like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divideby zero error"), we also need to prevent that same crash from happeningin the udlfb driver as it uses pixclock directly when dividing, whichwill 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: clamp report_size in s32ton() to avoid undefined shifts32ton() shifts by n-1 where n is the field's report_size, a value thatcomes directly from a HID device. The HID parser bounds report_sizeonly to <= 256, so a broken HID device can supply a report descriptorwith a wide field that triggers shift exponents up to 256 on a 32-bittype when an output report is built via hid_output_field() orhid_set_field().Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds inhid_report_raw_event") added the same n > 32 clamp to the functionsnto32(), but s32ton() was never given the same fix as I guess syzbothadn't figured out how to fuzz a device the same way.Fix this up by just clamping the max value of n, just like snto32()does.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: proc: size address buffers for %pISpc outputThe AF_RXRPC procfs helpers format local and remote socket addresses intofixed 50-byte stack buffers with "%pISpc".That is too small for the longest current-tree IPv6-with-port form theformatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses adotted-quad tail not only for v4mapped addresses, but also for ISATAPaddresses via ipv6_addr_is_isatap().As a result, a case such as [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535is possible with the current formatter. That is 50 visible characters, so51 bytes including the trailing NUL, which does not fit in the existingchar[50] buffers used by net/rxrpc/proc.c.Size the buffers from the formatter's maximum textual form and switch thecall sites to scnprintf().Changes since v1:- correct the changelog to cite the actual maximum current-tree case explicitly- frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: reject undecryptable rxkad response ticketsrxkad_decrypt_ticket() decrypts the RXKAD response ticket and thenparses the buffer as plaintext without checking whethercrypto_skcipher_decrypt() succeeded.A malformed RESPONSE can therefore use a non-block-aligned ticketlength, make the decrypt operation fail, and still drive the ticketparser with attacker-controlled bytes.Check the decrypt result and abort the connection with RXKADBADTICKETwhen ticket decryption 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mmc: vub300: fix NULL-deref on disconnectMake sure to deregister the controller before dropping the reference tothe driver data on disconnect to avoid NULL-pointer dereferences oruse-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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmsmac: Fix dma_free_coherent() sizedma_alloc_consistent() may change the size to align it. The new size issaved in alloced.Change the free size to match the allocation 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: clear trailing padding in build_polexpire()build_expire() clears the trailing padding bytes of structxfrm_user_expire after setting the hard field via memset_after(),but the analogous function build_polexpire() does not do this forstruct xfrm_user_polexpire.The padding bytes after the __u8 hard field are leftuninitialized from the heap allocation, and are then sent touserspace via netlink multicast to XFRMNLGRP_EXPIRE listeners,leaking kernel heap memory contents.Add the missing memset_after() call, matching build_expire().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: rfkill: prevent unlimited numbers of rfkill events from being createdUserspace can create an unlimited number of rfkill events if the systemis so configured, while not consuming them from the rfkill filedescriptor, causing a potential out of memory situation. Prevent thisfrom bounding the number of pending rfkill events at a "large" number(i.e. 1000) to prevent abuses like 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check()Reject rt match rules whose addrnr exceeds IP6T_RT_HOPS.rt_mt6() expects addrnr to stay within the bounds of rtinfo->addrs[].Validate addrnr during rule installation so malformed rules are rejectedbefore the match logic can use an out-of-range 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - limit RX SG extraction by receive buffer budgetMake af_alg_get_rsgl() limit each RX scatterlist extraction to theremaining receive buffer budget.af_alg_get_rsgl() currently uses af_alg_readable() only as a gatebefore extracting data into the RX scatterlist. Limit each extractionto the remaining af_alg_rcvbuf(sk) budget so that receive-sideaccounting matches the amount of data attached to the request.If skcipher cannot obtain enough RX space for at least one chunk whilemore data remains to be processed, reject the recvmsg call instead ofrounding the request length down to zero.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix missing validation of ticket length in non-XDR key preparsingIn rxrpc_preparse(), there are two paths for parsing key payloads: theXDR path (for large payloads) and the non-XDR path (for payloads <= 28bytes). While the XDR path (rxrpc_preparse_xdr_rxkad()) correctlyvalidates the ticket length against AFSTOKEN_RK_TIX_MAX, the non-XDRpath fails to do so.This allows an unprivileged user to provide a very large ticket length.When this key is later read via rxrpc_read(), the totaltoken size (toksize) calculation results in a value that exceedsAFSTOKEN_LENGTH_MAX, triggering a WARN_ON().[ 2001.302904] WARNING: CPU: 2 PID: 2108 at net/rxrpc/key.c:778 rxrpc_read+0x109/0x5c0 [rxrpc]Fix this by adding a check in the non-XDR parsing path of rxrpc_preparse()to ensure the ticket length does not exceed AFSTOKEN_RK_TIX_MAX,bringing it into parity with the XDR parsing logic.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: Fix resource leaks on errors in gpiochip_add_data_with_key()Since commit aab5c6f20023 ("gpio: set device type for GPIO chips"),`gdev->dev.release` is unset. As a result, the reference count to`gdev->dev` isn't dropped on the error handling paths.Drop the reference on errors.Also reorder the instructions to make the error handling simpler.Now gpiochip_add_data_with_key() roughly looks like: >>> Some memory allocation. Go to ERR ZONE 1 on errors. >>> device_initialize(). gpiodev_release() takes over the responsibility for freeing the resources of `gdev->dev`. The subsequent error handling paths shouldn't go through ERR ZONE 1 again which leads to double free. >>> Some initialization mainly on `gdev`. >>> The rest of initialization. Go to ERR ZONE 2 on errors. >>> Chip registration success and exit. >>> ERR ZONE 2. gpio_device_put() and exit. >>> ERR ZONE 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ftgmac100: fix ring allocation unwind on open failureftgmac100_alloc_rings() allocates rx_skbs, tx_skbs, rxdes, txdes, andrx_scratch in stages. On intermediate failures it returned -ENOMEMdirectly, leaking resources allocated earlier in the function.Rework the failure path to use staged local unwind labels and freeallocated resources in reverse order before returning -ENOMEM. Thismatches common netdev allocation cleanup style.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: ni_atmio16d: Fix invalid clean-up after failed attachIf the driver's COMEDI "attach" handler function (`atmio16d_attach()`)returns an error, the COMEDI core will call the driver's "detach"handler function (`atmio16d_detach()`) to clean up. This calls`reset_atmio16d()` unconditionally, but depending on where the erroroccurred in the attach handler, the device may not have beensufficiently initialized to call `reset_atmio16d()`. It uses`dev->iobase` as the I/O port base address and `dev->private` as thepointer to the COMEDI device's private data structure. `dev->iobase`may still be set to its initial value of 0, which would result inundesired writes to low I/O port addresses. `dev->private` may still be`NULL`, which would result in null pointer dereferences.Fix `atmio16d_detach()` by checking that `dev->private` is valid(non-null) before calling `reset_atmio16d()`. This implies that`dev->iobase` was set correctly since that is set up before`dev->private`.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: dt2815: add hardware detection to prevent crashThe dt2815 driver crashes when attached to I/O ports without actualhardware present. This occurs because syzkaller or users can attachthe driver to arbitrary I/O addresses via COMEDI_DEVCONFIG ioctl.When no hardware exists at the specified port, inb() operations return0xff (floating bus), but outb() operations can trigger page faults dueto undefined behavior, especially under race conditions: BUG: unable to handle page fault for address: 000000007fffff90 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page RIP: 0010:dt2815_attach+0x6e0/0x1110Add hardware detection by reading the status register before attemptingany write operations. If the read returns 0xff, assume no hardware ispresent and fail the attach with -ENODEV. This prevents crashes fromoutb() operations on non-existent hardware.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: gyro: mpu3050: Fix irq resource leakThe interrupt handler is setup but only a few lines down ifiio_trigger_register() fails the function returns without properlyreleasing the handler.Add cleanup goto to resolve resource leak.Detected by Smatch:drivers/iio/gyro/mpu3050-core.c:1128 mpu3050_trigger_probe() warn:'irq' from request_threaded_irq() not released on lines: 1124.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: SMP: derive legacy responder STK authentication from MITM stateThe legacy responder path in smp_random() currently labels the storedSTK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH.That reflects what the local service requested, not what the pairingflow actually achieved.For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clearand the resulting STK should remain unauthenticated even if the localside requested HIGH security. Use the established MITM state whenstoring the responder STK so the key metadata matches the pairing result.This also keeps the legacy path aligned with the Secure Connections code,which already treats JUST_WORKS/JUST_CFM as unauthenticated.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: ctxfi: Check the error for index mappingThe ctxfi driver blindly assumed a proper value returned fromdaio_device_index(), but it's not always true. Add a proper errorcheck to deal with the error from 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculationThe variable valuesize is declared as u8 but accumulates the totallength of all SSIDs to scan. Each SSID contributes up to 33 bytes(IEEE80211_MAX_SSID_LEN + 1), and with WILC_MAX_NUM_PROBED_SSID (10)SSIDs the total can reach 330, which wraps around to 74 when storedin a u8.This causes kmalloc to allocate only 75 bytes while the subsequentmemcpy writes up to 331 bytes into the buffer, resulting in a 256-byteheap buffer overflow.Widen valuesize from u8 to u32 to accommodate the full 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/ioc32: stop speculation on the drm_compat_ioctl pathThe drm compat ioctl path takes a user controlled pointer, and thendereferences it into a table of function pointers, the signature methodof spectre problems. Fix this up by calling array_index_nospec() on theindex to the function pointer 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen/privcmd: fix double free via VMA splittingprivcmd_vm_ops defines .close (privcmd_close), but neither .may_splitnor .open. When userspace does a partial munmap() on a privcmd mapping,the kernel splits the VMA via __split_vma(). Since may_split is NULL,the split is allowed. vm_area_dup() copies vm_private_data (a pagesarray allocated in alloc_empty_pages()) into the new VMA without anyfixup, because there is no .open callback.Both VMAs now point to the same pages array. When the unmapped portionis closed, privcmd_close() calls: - xen_unmap_domain_gfn_range() - xen_free_unpopulated_pages() - kvfree(pages)The surviving VMA still holds the dangling pointer. When it is laterdestroyed, the same sequence runs again, which leads to a double free.Fix this issue by adding a .may_split callback denying the VMA split.This is XSA-487 / CVE-2026-31787
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. Prior to version 0.9-rc4, any unprivileged local user can crash avahi-daemon by sending a single D-Bus method call with conflicting publish flags. This issue has been patched in version 0.9-rc4.
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.39.1).
-
Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.16 and prior, an integer underflow vulnerability in _ppdCreateFromIPP() (cups/ppd-cache.c) allows any unprivileged local user to crash the cupsd root process by supplying a negative job-password-supported IPP attribute. The bounds check only caps the upper bound, so a negative value passes validation, is cast to size_t (wrapping to ~2^64), and is used as the length argument to memset() on a 33-byte stack buffer. This causes an immediate SIGSEGV in the cupsd root process. Combined with systemd's Restart=on-failure, an attacker can repeat the crash for sustained denial of service.
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.62.1).
-
Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.16 and prior, a use-after-free vulnerability exists in the CUPS scheduler (cupsd) when temporary printers are automatically deleted. cupsdDeleteTemporaryPrinters() in scheduler/printers.c calls cupsdDeletePrinter() without first expiring subscriptions that reference the printer, leaving cupsd_subscription_t.dest as a dangling pointer to freed heap memory. The dangling pointer is subsequently dereferenced at multiple code sites, causing a crash (denial of service) of the cupsd daemon. With heap grooming, this can be leveraged for code execution.
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.62.1).
-
Description: Unknown.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python-pyOpenSSL > 0-0 (version in image is 17.1.0-4.32.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: macb: properly unregister fixed rate clocksThe additional resources allocated with clk_register_fixed_rate() needto be released with clk_unregister_fixed_rate(), otherwise they are lost.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: macb: fix clk handling on PCI glue driver removalplatform_device_unregister() may still want to use the registered clksduring runtime resume callback.Note that there is a commit d82d5303c4c5 ("net: macb: fix use after freeon rmmod") that addressed the similar problem of clk vs platform deviceunregistration but just moved the bug to another place.Save the pointers to clks into local variables for reuse after platformdevice is unregistered.BUG: KASAN: use-after-free in clk_prepare+0x5a/0x60Read of size 8 at addr ffff888104f85e00 by task modprobe/597CPU: 2 PID: 597 Comm: modprobe Not tainted 6.1.164+ #114Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x8d/0xba print_report+0x17f/0x496 kasan_report+0xd9/0x180 clk_prepare+0x5a/0x60 macb_runtime_resume+0x13d/0x410 [macb] pm_generic_runtime_resume+0x97/0xd0 __rpm_callback+0xc8/0x4d0 rpm_callback+0xf6/0x230 rpm_resume+0xeeb/0x1a70 __pm_runtime_resume+0xb4/0x170 bus_remove_device+0x2e3/0x4b0 device_del+0x5b3/0xdc0 platform_device_del+0x4e/0x280 platform_device_unregister+0x11/0x50 pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 519: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x8e/0x90 __clk_register+0x458/0x2890 clk_hw_register+0x1a/0x60 __clk_hw_register_fixed_rate+0x255/0x410 clk_register_fixed_rate+0x3c/0xa0 macb_probe+0x1d8/0x42e [macb_pci] local_pci_probe+0xd7/0x190 pci_device_probe+0x252/0x600 really_probe+0x255/0x7f0 __driver_probe_device+0x1ee/0x330 driver_probe_device+0x4c/0x1f0 __driver_attach+0x1df/0x4e0 bus_for_each_dev+0x15d/0x1f0 bus_add_driver+0x486/0x5e0 driver_register+0x23a/0x3d0 do_one_initcall+0xfd/0x4d0 do_init_module+0x18b/0x5a0 load_module+0x5663/0x7950 __do_sys_finit_module+0x101/0x180 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8Freed by task 597: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x106/0x180 __kmem_cache_free+0xbc/0x320 clk_unregister+0x6de/0x8d0 macb_remove+0x73/0xc0 [macb_pci] pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: validate LTK enc_size on loadLoad Long Term Keys stores the user-provided enc_size and later usesit to size fixed-size stack operations when replying to LE LTKrequests. An enc_size larger than the 16-byte key buffer can thereforeoverflow the reply stack buffer.Reject oversized enc_size values while validating the management LTKrecord so invalid keys never reach the stored key 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: reject immediate NF_QUEUE verdictnft_queue is always used from userspace nftables to deliver the NF_QUEUEverdict. Immediately emitting an NF_QUEUE verdict is never used by theuserspace nft tools, so reject immediate NF_QUEUE verdicts.The arp family does not provide queue support, but such an immediateverdict is still reachable. Globally reject NF_QUEUE immediate verdictsto address 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absentctnetlink_alloc_expect() allocates expectations from a non-zeroingslab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is notpresent in the netlink message, saved_addr and saved_proto arenever initialized. Stale data from a previous slab occupant canthen be dumped to userspace by ctnetlink_exp_dump_expect(), whichchecks these fields to decide whether to emit CTA_EXPECT_NAT.The safe sibling nf_ct_expect_init(), used by the packet path,explicitly zeroes these fields.Zero saved_addr, saved_proto and dir in the else branch, guardedby IS_ENABLED(CONFIG_NF_NAT) since these fields only exist whenNAT is enabled.Confirmed by priming the expect slab with NAT-bearing expectations,freeing them, creating a new expectation without CTA_EXPECT_NAT,and observing that the ctnetlink dump emits a spuriousCTA_EXPECT_NAT containing stale data from the prior 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: x_tables: ensure names are nul-terminatedReject names that lack a \0 character before feeding themto functions that expect c-strings.Fixes tag is the most recent commit that needs this change.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: authencesn - Do not place hiseq at end of dst for out-of-place decryptionWhen decrypting data that is not in-place (src != dst), there isno need to save the high-order sequence bits in dst as it couldsimply be re-copied from the source.However, the data to be hashed need to be rearranged accordingly.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: cls_api: fix tc_chain_fill_node to initialize tcm_info to zero to prevent an info-leakWhen building netlink messages, tc_chain_fill_node() never initializesthe tcm_info field of struct tcmsg. Since the allocation is not zeroed,kernel heap memory is leaked to userspace through this 4-byte field.The fix simply zeroes tcm_info alongside the other fields that arealready 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: use skb_header_pointer() for TCPv4 GSO frag_off checkSyzbot reported a KMSAN uninit-value warning in gso_features_check()called from netif_skb_features() [1].gso_features_check() reads iph->frag_off to decide whether to clearmangleid_features. Accessing the IPv4 header via ip_hdr()/inner_ip_hdr()can rely on skb header offsets that are not always safe for directdereference on packets injected from PF_PACKET paths.Use skb_header_pointer() for the TCPv4 frag_off check so the header readis robust whether data is already linear or needs copying.[1] https://syzkaller.appspot.com/bug?extid=1543a7d954d9c6d00407
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and ip6ip6_err() to prevent this?This patch implements the first suggestion.I am not sure if ip6ip6_err() needs to be changed.A separate patch would be better 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leakWhen processing Router Advertisements with user options the kernelbuilds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg structhas three padding fields that are never zeroed and can leak kernel dataThe fix is simple, just zeroes the padding fields.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mpls: add seqcount to protect the platform_label{,s} pairThe RCU-protected codepaths (mpls_forward, mpls_dump_routes) can havean inconsistent view of platform_labels vs platform_label in case of aconcurrent resize (resize_platform_label_table, underplatform_mutex). This can lead to OOB accesses.This patch adds a seqcount, so that we get a consistent snapshot.Note that mpls_label_ok is also susceptible to this, so the checkagainst RTA_DST in rtm_to_route_config, done outside platform_mutex,is not sufficient. This value gets passed to mpls_label_ok once morein both mpls_route_add and mpls_route_del, so there is no issue, butthat additional check must not be 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af-alg - fix NULL pointer dereference in scatterwalkThe AF_ALG interface fails to unmark the end of a Scatter/Gather List (SGL)when chaining a new af_alg_tsgl structure. If a sendmsg() fills an SGLexactly to MAX_SGL_ENTS, the last entry is marked as the end. A subsequentsendmsg() allocates a new SGL and chains it, but fails to clear the endmarker on the previous SGL's last data entry.This causes the crypto scatterwalk to hit a premature end, returning NULLon sg_next() and leading to a kernel panic during dereference.Fix this by explicitly unmarking the end of the previous SGL whenperforming sg_chain() in af_alg_alloc_tsgl().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: reject root items with drop_progress and zero drop_level[BUG]When recovering relocation at mount time, merge_reloc_root() andbtrfs_drop_snapshot() both use BUG_ON(level == 0) to guard againstan impossible state: a non-zero drop_progress combined with a zerodrop_level in a root_item, which can be triggered:------------[ cut here ]------------kernel BUG at fs/btrfs/relocation.c:1545!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTICPU: 1 UID: 0 PID: 283 ... Tainted: 6.18.0+ #16 PREEMPT(voluntary)Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULEHardware name: QEMU Ubuntu 24.04 PC v2, BIOS 1.16.3-debian-1.16.3-2RIP: 0010:merge_reloc_root+0x1266/0x1650 fs/btrfs/relocation.c:1545Code: ffff0000 00004589 d7e9acfa ffffe8a1 79bafebe 02000000Call Trace: merge_reloc_roots+0x295/0x890 fs/btrfs/relocation.c:1861 btrfs_recover_relocation+0xd6e/0x11d0 fs/btrfs/relocation.c:4195 btrfs_start_pre_rw_mount+0xa4d/0x1810 fs/btrfs/disk-io.c:3130 open_ctree+0x5824/0x5fe0 fs/btrfs/disk-io.c:3640 btrfs_fill_super fs/btrfs/super.c:987 [inline] btrfs_get_tree_super fs/btrfs/super.c:1951 [inline] btrfs_get_tree_subvol fs/btrfs/super.c:2094 [inline] btrfs_get_tree+0x111c/0x2190 fs/btrfs/super.c:2128 vfs_get_tree+0x9a/0x370 fs/super.c:1758 fc_mount fs/namespace.c:1199 [inline] do_new_mount_fc fs/namespace.c:3642 [inline] do_new_mount fs/namespace.c:3718 [inline] path_mount+0x5b8/0x1ea0 fs/namespace.c:4028 do_mount fs/namespace.c:4041 [inline] __do_sys_mount fs/namespace.c:4229 [inline] __se_sys_mount fs/namespace.c:4206 [inline] __x64_sys_mount+0x282/0x320 fs/namespace.c:4206 ...RIP: 0033:0x7f969c9a8fdeCode: 0f1f4000 48c7c2b0 fffffff7 d8648902 b8ffffff ffc3660f---[ end trace 0000000000000000 ]---The bug is reproducible on 7.0.0-rc2-next-20260310 with our dynamicmetadata fuzzing tool that corrupts btrfs metadata at runtime.[CAUSE]A non-zero drop_progress.objectid means an interruptedbtrfs_drop_snapshot() left a resume point on disk, and in that casedrop_level must be greater than 0 because the checkpoint is onlysaved at internal node levels.Although this invariant is enforced when the kernel writes the rootitem, it is not validated when the root item is read back from disk.That allows on-disk corruption to provide an invalid state withdrop_progress.objectid != 0 and drop_level == 0.When relocation recovery later processes such a root item,merge_reloc_root() reads drop_level and hits BUG_ON(level == 0). Thesame invalid metadata can also trigger the corresponding BUG_ON() inbtrfs_drop_snapshot().[FIX]Fix this by validating the root_item invariant in tree-checker whenreading root items from disk: if drop_progress.objectid is non-zero,drop_level must also be non-zero. Reject such malformed metadata with-EUCLEAN before it reaches merge_reloc_root() or btrfs_drop_snapshot()and triggers the BUG_ON.After the fix, the same corruption is correctly rejected by tree-checkerand the BUG_ON is no longer 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: multitouch: Check to ensure report responses match the requestIt is possible for a malicious (or clumsy) device to respond to aspecific report's feature request using a completely different reportID. This can cause confusion in the HID core resulting in nastyside-effects such as OOB writes.Add a check to ensure that the report ID in the response, matches theone that was requested. If it doesn't, omit reporting the raw event andreturn early.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: Mitigate potential OOB by removing bogus memset()The memset() in hid_report_raw_event() has the good intention ofclearing out bogus data by zeroing the area from the end of the incomingdata string to the assumed end of the buffer. However, as we havepreviously seen, doing so can easily result in OOB reads and writes inthe subsequent thread of execution.The current suggestion from one of the HID maintainers is to remove thememset() and simply return if the incoming event buffer size is notlarge enough to fill the associated report.Suggested-by Benjamin Tissoires [bentiss: changed the return 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irqThe wacom_intuos_bt_irq() function processes Bluetooth HID reportswithout sufficient bounds checking. A maliciously crafted short reportcan trigger an out-of-bounds read when copying data into the wacomstructure.Specifically, report 0x03 requires at least 22 bytes to safely readthe processed data and battery status, while report 0x04 (whichfalls through to 0x03) requires 32 bytes.Add explicit length checks for these report IDs and log a warning ifa short report is received.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_ll: Fix firmware leak on error pathSmatch reports:drivers/bluetooth/hci_ll.c:587 download_firmware() warn:'fw' from request_firmware() not released on lines: 544.In download_firmware(), if request_firmware() succeeds but the returnedfirmware content is invalid (no data or zero size), the function returnswithout releasing the firmware, resulting in a resource leak.Fix this by calling release_firmware() before returning whenrequest_firmware() succeeded but the firmware content is 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsglWhen page reassignment was added to af_alg_pull_tsgl the originalloop wasn't updated so it may try to reassign one more page thannecessary.Add the check to the reassignment so that this does not happen.Also update the comment which still refers to the obsolete offsetargument.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: Drop large packets with UDP encapsyzbot reported a WARN on my patch series [1]. The actual issue is anoverflow of 16-bit UDP length field, and it exists in the upstream code.My series added a debug WARN with an overflow check that exposed theissue, that's why syzbot tripped on my patches, rather than on upstreamcode.syzbot's repro:r0 = socket$pppl2tp(0x18, 0x1, 0x1)r1 = socket$inet6_udp(0xa, 0x2, 0x0)connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c)connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={'\x00', '\xff\xff', @empty}}}}, 0x32)writev(r0, &(0x7f0000000080)=[{&(0x7f0000000000)="ee", 0x34000}], 0x1)It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDPencapsulation, and l2tp_xmit_core doesn't check for overflows when itassigns the UDP length field. The value gets trimmed to 16 bites.Add an overflow check that drops oversized packets and avoids sendingpackets with trimmed UDP length to the wire.syzbot's stack trace (with my patch applied):len >= 65536uWARNING: ./include/linux/udp.h:38 at udp_set_len_short include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957WARNING: ./include/linux/udp.h:38 at l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline], CPU#1: syz.0.17/5957WARNING: ./include/linux/udp.h:38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327, CPU#1: syz.0.17/5957Modules linked in:CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014RIP: 0010:udp_set_len_short include/linux/udp.h:38 [inline]RIP: 0010:l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline]RIP: 0010:l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4fRSP: 0018:ffffc90003d67878 EFLAGS: 00010293RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffffRBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0Call Trace: pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c:302 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] sock_write_iter+0x503/0x550 net/socket.c:1195 do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1 vfs_writev+0x33c/0x990 fs/read_write.c:1059 do_writev+0x154/0x2e0 fs/read_write.c:1105 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f636479c629Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0 [1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminatorWhen batching multiple NFLOG messages (inst->qlen > 1), __nfulnl_send()appends an NLMSG_DONE terminator with sizeof(struct nfgenmsg) payload vianlmsg_put(), but never initializes the nfgenmsg bytes. The nlmsg_put()helper only zeroes alignment padding after the payload, not the payloaditself, so four bytes of stale kernel heap data are leaked to userspacein the NLMSG_DONE message body.Use nfnl_msg_put() to build the NLMSG_DONE terminator, which initializesthe nfgenmsg payload via nfnl_fill_hdr(), consistent with how__build_packet_message() already constructs NFULNL_MSG_PACKET headers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm_user: fix info leak in build_mapping()struct xfrm_usersa_id has a one-byte padding hole after the protofield, which ends up never getting set to zero before copying out touserspace. Fix that up by zeroing out the whole structure beforesetting individual variables.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Wait for RCU readers during policy netns exitxfrm_policy_fini() frees the policy_bydst hash tables after flushing thepolicy work items and deleting all policies, but it does not wait forconcurrent RCU readers to leave their read-side critical sections first.The policy_bydst tables are published via rcu_assign_pointer() and arelooked up through rcu_dereference_check(), so netns teardown must alsowait for an RCU grace period before freeing the table memory.Fix this by adding synchronize_rcu() before freeing the policy hash tables.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xsk: tighten UMEM headroom validation to account for tailroom and min frameThe current headroom validation in xdp_umem_reg() could leave us withinsufficient space dedicated to even receive minimum-sized ethernetframe. Furthermore if multi-buffer would come to play thenskb_shared_info stored at the end of XSK frame would be corrupted.HW typically works with 128-aligned sizes so let us provide this valueas bare minimum.Multi-buffer setting is known later in the configuration process sobesides accounting for 128 bytes, let us also take care of tailroom spaceupfront.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: lapbether: handle NETDEV_PRE_TYPE_CHANGElapbeth_data_transmit() expects the underlying device typeto be ARPHRD_ETHER.Returning NOTIFY_BAD from lapbeth_device_event() makes surebonding driver can not break this expectation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vc4: Fix a memory leak in hang state error pathWhen vc4_save_hang_state() encounters an early return condition, itreturns without freeing the previously allocated `kernel_state`,leaking memory.Add the missing kfree() calls by consolidating the early return pathsinto a single place.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vc4: Fix memory leak of BO array in hang stateThe hang state's BO array is allocated separately with kzalloc() invc4_save_hang_state() but never freed in vc4_free_hang_state(). Add themissing kfree() for the BO array before freeing the hang state struct.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wl1251: validate packet IDs before indexing tx_frameswl1251_tx_packet_cb() uses the firmware completion ID directly to indexthe fixed 16-entry wl->tx_frames[] array. The ID is a raw u8 from thecompletion block, and the callback does not currently verify that itfits the array before dereferencing it.Reject completion IDs that fall outside wl->tx_frames[] and keep theexisting NULL check in the same guard. This keeps the fix local to thetrust boundary and avoids touching the rest of the completion flow.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:srcu: Use irq_work to start GP in tiny SRCUTiny SRCU's srcu_gp_start_if_needed() directly calls schedule_work(),which acquires the workqueue pool->lock.This causes a lockdep splat when call_srcu() is called with a schedulerlock held, due to: call_srcu() [holding pi_lock] srcu_gp_start_if_needed() schedule_work() -> pool->lock workqueue_init() / create_worker() [holding pool->lock] wake_up_process() -> try_to_wake_up() -> pi_lockAlso add irq_work_sync() to cleanup_srcu_struct() to prevent ause-after-free if a queued irq_work fires after cleanup begins.Tested with rcutorture SRCU-T and no lockdep warnings.[ Thanks to Boqun for similar fix in patch "rcu: Use an intermediate irq_workto start process_srcu()" ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: ensure safe access to master conntrackHolding reference on the expectation is not sufficient, the masterconntrack object can just go away, making exp->master invalid.To access exp->master safely:- Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away.- Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths.This patch goes for extending the nf_conntrack_expect_lock sectionto address this issue for simplicity, in the cases that are describedbelow this is just slightly extending the lock section.The add expectation command already holds a reference to the masterconntrack from ctnetlink_create_expect().However, the delete expectation command needs to grab the spinlockbefore looking up for the expectation. Expand the existing spinlocksection to address this to cover the expectation lookup. Note that,the nf_ct_expect_iterate_net() calls already grabs the spinlock whileiterating over the expectation table, which is correct.The get expectation command needs to grab the spinlock to ensure masterconntrack does not go away. This also expands the existing spinlocksection to cover the expectation lookup too. I needed to move thenetlink skb allocation out of the spinlock to keep it GFP_KERNEL.For the expectation events, the IPEXP_DESTROY event is already deliveredunder the spinlock, just move the delivery of IPEXP_NEW under thespinlock too because the master conntrack event cache is reached throughexp->master.While at it, add lockdep notations to help identify what codepaths needto grab the spinlock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file()If overlay is used on top of btrfs, dentry->d_sb translates to overlay'ssuper block and fsid assignment will lead to a crash.Use file_inode(file)->i_sb to always get btrfs_sb.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: check return value of con2fb_acquire_newinfo()If fbcon_open() fails when called from con2fb_acquire_newinfo() theninfo->fbcon_par pointer remains NULL which is later dereferenced.Add check for return value of the function con2fb_acquire_newinfo() toavoid it.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pstore: ram_core: fix incorrect success return when vmap() failsIn persistent_ram_vmap(), vmap() may return NULL on failure.If offset is non-zero, adding offset_in_page(start) causes the functionto return a non-NULL pointer even though the mapping failed.persistent_ram_buffer_map() therefore incorrectly returns success.Subsequent access to prz->buffer may dereference an invalid addressand cause crashes.Add proper NULL checking for vmap() failures.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dlm: validate length in dlm_search_rsb_treeThe len parameter in dlm_dump_rsb_name() is not validated and comesfrom network messages. When it exceeds DLM_RESNAME_MAXLEN, it cancause out-of-bounds write in dlm_search_rsb_tree().Add length validation to prevent potential 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm-verity: correctly handle dm_bufio_client_create() failureIf either of the calls to dm_bufio_client_create() in verity_fec_ctr()fails, then dm_bufio_client_destroy() is later called with an ERR_PTR()argument. That causes a crash. 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQThis adds a check for encryption key size upon receivingL2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C whichexpects L2CAP_CR_LE_BAD_KEY_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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm6: fix uninitialized saddr in xfrm6_get_saddr()xfrm6_get_saddr() does not check the return value ofipv6_dev_get_saddr(). When ipv6_dev_get_saddr() fails to find a suitablesource address (returns -EADDRNOTAVAIL), saddr->in6 is leftuninitialized, but xfrm6_get_saddr() still returns 0 (success).This causes the caller xfrm_tmpl_resolve_one() to use the uninitializedaddress in xfrm_state_find(), triggering KMSAN warning:=====================================================BUG: KMSAN: uninit-value in xfrm_state_find+0x2424/0xa940 xfrm_state_find+0x2424/0xa940 xfrm_resolve_and_create_bundle+0x906/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 xfrm_lookup_route+0x63/0x2b0 ip_route_output_flow+0x1ce/0x270 udp_sendmsg+0x2ce1/0x3400 inet_sendmsg+0x1ef/0x2a0 __sock_sendmsg+0x278/0x3d0 __sys_sendto+0x593/0x720 __x64_sys_sendto+0x130/0x200 x64_sys_call+0x332b/0x3e70 do_syscall_64+0xd3/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7fLocal variable tmp.i.i created at: xfrm_resolve_and_create_bundle+0x3e3/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770=====================================================Fix by checking the return value of ipv6_dev_get_saddr() and propagatingthe 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Revert "PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV"This reverts commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove lockingwhen enabling/disabling SR-IOV"), which causes a deadlock by recursivelytaking pci_rescan_remove_lock when sriov_del_vfs() is called as part ofpci_stop_and_remove_bus_device(). For example with the following sequenceof commands: $ echo
> /sys/bus/pci/devices//sriov_numvfs $ echo 1 > /sys/bus/pci/devices//removeA trimmed trace of the deadlock on a mlx5 device is as below: zsh/5715 is trying to acquire lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140 but task is already holding lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80 ... Call Trace: [<00000259778c4f90>] dump_stack_lvl+0xc0/0x110 [<00000259779c844e>] print_deadlock_bug+0x31e/0x330 [<00000259779c1908>] __lock_acquire+0x16c8/0x32f0 [<00000259779bffac>] lock_acquire+0x14c/0x350 [<00000259789643a6>] __mutex_lock_common+0xe6/0x1520 [<000002597896413c>] mutex_lock_nested+0x3c/0x50 [<00000259784a07e4>] sriov_disable+0x34/0x140 [<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core] [<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core] [<00000259784857fc>] pci_device_remove+0x3c/0xa0 [<000002597851012e>] device_release_driver_internal+0x18e/0x280 [<000002597847ae22>] pci_stop_bus_device+0x82/0xa0 [<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80 [<00000259784972c2>] remove_store+0x72/0x90 [<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200 [<0000025977d7241c>] vfs_write+0x24c/0x300 [<0000025977d72696>] ksys_write+0x86/0x110 [<000002597895b61c>] __do_syscall+0x14c/0x400 [<000002597896e0ee>] system_call+0x6e/0x90This alone is not a complete fix as it restores the issue the cited committried to solve. A new fix will be provided as a follow 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: wan/fsl_ucc_hdlc: Fix dma_free_coherent() in uhdlc_memclean()The priv->rx_buffer and priv->tx_buffer are alloc'd together ascontiguous buffers in uhdlc_init() but freed as two buffers inuhdlc_memclean().Change the cleanup to only call dma_free_coherent() once on the wholebuffer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: hid-pl: handle probe errorsErrors in init must be reported back or we'llfollow a NULL pointer the first time FF 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: pegasus: enable basic endpoint checkingpegasus_probe() fills URBs with hardcoded endpoint pipes withoutverifying the endpoint descriptors: - usb_rcvbulkpipe(dev, 1) for RX data - usb_sndbulkpipe(dev, 2) for TX data - usb_rcvintpipe(dev, 3) for status interruptsA malformed USB device can present these endpoints with transfer typesthat differ from what the driver assumes.Add a pegasus_usb_ep enum for endpoint numbers, replacing magicconstants throughout. Add usb_check_bulk_endpoints() andusb_check_int_endpoints() calls before any resource allocation toverify endpoint types before use, rejecting devices with mismatcheddescriptors at probe time, and avoid triggering assertion.Similar fix to- commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking")- commit 9e7021d2aeae ("net: usb: catc: enable basic endpoint checking")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix null dereference in find_networkThe variable pwlan has the possibility of being NULL when passed intortw_free_network_nolock() which would later dereference the variable.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/bitmap: fix GPF in write_page caused by resize raceA General Protection Fault occurs in write_page() during array resize:RIP: 0010:write_page+0x22b/0x3c0 [md_mod]This is a use-after-free race between bitmap_daemon_work() and__bitmap_resize(). The daemon iterates over `bitmap->storage.filemap`without locking, while the resize path frees that storage viamd_bitmap_file_unmap(). `quiesce()` does not stop the md thread,allowing concurrent access to freed pages.Fix by holding `mddev->bitmap_info.mutex` during the bitmap update.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: always flush state and policy upon NETDEV_UNREGISTER eventsyzbot is reporting that "struct xfrm_state" refcount is leaking. unregister_netdevice: waiting for netdevsim0 to become free. Usage count = 2 ref_tracker: netdev@ffff888052f24618 has 1/1 users at __netdev_tracker_alloc include/linux/netdevice.h:4400 [inline] netdev_tracker_alloc include/linux/netdevice.h:4412 [inline] xfrm_dev_state_add+0x3a5/0x1080 net/xfrm/xfrm_device.c:316 xfrm_state_construct net/xfrm/xfrm_user.c:986 [inline] xfrm_add_sa+0x34ff/0x5fa0 net/xfrm/xfrm_user.c:1022 xfrm_user_rcv_msg+0x58e/0xc00 net/xfrm/xfrm_user.c:3507 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2550 xfrm_netlink_rcv+0x71/0x90 net/xfrm/xfrm_user.c:3529 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa5d/0xc30 net/socket.c:2592 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2646 __sys_sendmsg+0x16d/0x220 net/socket.c:2678 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fThis is because commit d77e38e612a0 ("xfrm: Add an IPsec hardwareoffloading API") implemented xfrm_dev_unregister() as no-op despitexfrm_dev_state_add() from xfrm_state_construct() acquires a referenceto "struct net_device".I guess that that commit expected that NETDEV_DOWN event is fired beforeNETDEV_UNREGISTER event fires, and also assumed that xfrm_dev_state_add()is called only if (dev->features & NETIF_F_HW_ESP) != 0.Sabrina Dubroca identified steps to reproduce the same symptoms as below. echo 0 > /sys/bus/netdevsim/new_device dev=$(ls -1 /sys/bus/netdevsim/devices/netdevsim0/net/) ip xfrm state add src 192.168.13.1 dst 192.168.13.2 proto esp \ spi 0x1000 mode tunnel aead 'rfc4106(gcm(aes))' $key 128 \ offload crypto dev $dev dir out ethtool -K $dev esp-hw-offload off echo 0 > /sys/bus/netdevsim/del_deviceLike these steps indicate, the NETIF_F_HW_ESP bit can be cleared afterxfrm_dev_state_add() acquired a reference to "struct net_device".Also, xfrm_dev_state_add() does not check for the NETIF_F_HW_ESP bitwhen acquiring a reference to "struct net_device".Commit 03891f820c21 ("xfrm: handle NETDEV_UNREGISTER for xfrm device")re-introduced the NETDEV_UNREGISTER event to xfrm_dev_event(), but thatcommit for unknown reason chose to share xfrm_dev_down() between theNETDEV_DOWN event and the NETDEV_UNREGISTER event.I guess that that commit missed the behavior in the previous paragraph.Therefore, we need to re-introduce xfrm_dev_unregister() in order torelease the reference to "struct net_device" by unconditionally flushingstate and 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix reflink preserve cleanup issuecommit c06c303832ec ("ocfs2: fix xattr array entry __counted_by error")doesn't handle all cases and the cleanup job for preserved xattr entriesstill has bug:- the 'last' pointer should be shifted by one unit after cleanup an array entry.- current code logic doesn't cleanup the first entry when xh_count is 1.Note, commit c06c303832ec is also a bug fix for 0fe9b66c65f3.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_modekaweth_set_rx_mode(), the ndo_set_rx_mode callback, callsnetif_stop_queue() and netif_wake_queue(). These are TX queue flowcontrol functions unrelated to RX multicast configuration.The premature netif_wake_queue() can re-enable TX while tx_urb is stillin-flight, leading to a double usb_submit_urb() on the same URB:kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb);}kaweth_set_rx_mode() { netif_stop_queue(); netif_wake_queue(); // wakes TX queue before URB is done}kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); // URB submitted while active}This triggers the WARN in usb_submit_urb(): "URB submitted while active"This is a similar class of bug fixed in rtl8150 by- commit 958baf5eaee3 ("net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast").Also kaweth_set_rx_mode() is already functionally broken, thereal set_rx_mode action is performed by kaweth_async_set_rx_mode(),which in turn is not a no-op only at ndo_open() 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: ccs: Avoid possible division by zeroCalculating maximum M for scaler configuration involves dividing byMIN_X_OUTPUT_SIZE limit register's value. Albeit the value is presumablynon-zero, the driver was missing the check it in fact was. 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: consume xmit errors of GSO framesudpgro_frglist.sh and udpgro_bench.sh are the flakiest testscurrently in NIPA. They fail in the same exact way, TCP GROtest stalls occasionally and the test gets killed after 10min.These tests use veth to simulate GRO. They attach a trivial("return XDP_PASS;") XDP program to the veth to force TSO offand NAPI on.Digging into the failure mode we can see that the connectionis completely stuck after a burst of drops. The sender's snd_nxtis at sequence number N [1], but the receiver claims to havereceived (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzleis that senders rtx queue is not empty (let's say the block inthe rtx queue is at sequence number N - 4 * MSS [3]).In this state, sender sends a retransmission from the rtx queuewith a single segment, and sequence numbers N-4*MSS:N-3*MSS [3].Receiver sees it and responds with an ACK all the way up toN + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATAbecause it has no recollection of ever sending data that far out [1].And we are stuck.The root cause is the mess of the xmit return codes. veth returnsan error when it can't xmit a frame. We end up with a loss eventlike this: ------------------------------------------------- | GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ------------------------------------------------- x ok ok | ok ok ok \\ snd_nxt"x" means packet lost by veth, and "ok" means it went thru.Since veth has TSO disabled in this test it sees individual segments.Segment 1 is on the retransmit queue and will be resent.So why did the sender not advance snd_nxt even tho it clearly didsend up to seg 8? tcp_write_xmit() interprets the return codefrom the core to mean that data has not been sent at all. SinceTCP deals with GSO super frames, not individual segment the cruxof the problem is that loss of a single segment can be interpretedas loss of all. TCP only sees the last return code for the lastsegment of the GSO frame (in <> brackets in the diagram above).Of course for the problem to occur we need a setup or a devicewithout a Qdisc. Otherwise Qdisc layer disconnects the protocollayer from the device errors completely.We have multiple ways to fix this. 1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great. 2) fix the damn return codes We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the documentation, so maybe we should make the return code from ndo_start_xmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer. 3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ip_queue_xmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss? 4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQ_F_CAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-"networks" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix?Similar fix has been proposed by Eric in the past but never committedbecause original reporter was working with an OOT driver and wasn'tproviding feedback (see Link).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: vt8500lcdfb: fix missing dma_free_coherent()fbi->fb.screen_buffer is allocated with dma_alloc_coherent() but is notfreed if the error path is reached.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set()The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8bytes via memset without checking the buffer size parameter. This allowsunprivileged userspace to trigger an out-of bounds kernel memory writeby passing a small buffer, leading to potential privilegeescalation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mtk-mdp: Fix error handling in probe functionAdd mtk_mdp_unregister_m2m_device() on the error handling path to preventresource leak.Add check for the return value of vpu_get_plat_device() to prevent nullpointer dereference. And vpu_get_plat_device() increases the referencecount of the returned platform device. Add platform_device_put() toprevent reference 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Fix pci_slot_trylock() error handlingCommit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()")delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() inpci_slot_trylock(), but it forgets to remove the correspondingpci_dev_unlock() when pci_bus_trylock() fails.Before a4e772898f8b, the code did: if (!pci_dev_trylock(dev)) /* <- lock bridge device */ goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); /* <- unlock bridge device */ goto unlock; } }After a4e772898f8b the bridge-device lock is no longer taken, but thepci_dev_unlock(dev) on the failure path was left in place, leading to thebug.This yields one of two errors: 1. A warning that the lock is being unlocked when no one holds it. 2. An incorrect unlock of a lock that belongs to another thread.Fix it by removing the now-redundant pci_dev_unlock(dev) on the failurepath.[Same patch later posted by Keith athttps://patch.msgid.link/20260116184150.3013258-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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: Drop the lock in skb_may_tx_timestamp()skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock mustnot be taken in IRQ context, only softirq is okay. A few drivers receivethe timestamp via a dedicated interrupt and complete the TX timestampfrom that handler. This will lead to a deadlock if the lock is alreadywrite-locked on the same CPU.Taking the lock can be avoided. The socket (pointed by the skb) willremain valid until the skb is released. The ->sk_socket and ->filemember will be set to NULL once the user closes the socket which mayhappen before the timestamp arrives.If we happen to observe the pointer while the socket is closing butbefore the pointer is set to NULL then we may use it because bothpointer (and the file's cred member) are RCU freed.Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add amatching WRITE_ONCE() where the pointer are cleared.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix memory leak on failure pathcfg80211_inform_bss_frame() may return NULL on failure. In that case,the allocated buffer 'buf' is not freed and the function returns early,leading to potential memory leak.Fix this by ensuring that 'buf' is freed on both success and failure paths.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/rds: No shortcut out of RDS_CONN_ERRORRDS connections carry a state "rds_conn_path::cp_state"and transitions from one state to another and are conditionalupon an expected state: "rds_conn_path_transition."There is one exception to this conditionality, which is"RDS_CONN_ERROR" that can be enforced by "rds_conn_path_drop"regardless of what state the condition is currently in.But as soon as a connection enters state "RDS_CONN_ERROR",the connection handling code expects it to go through theshutdown-path.The RDS/TCP multipath changes added a shortcut out of"RDS_CONN_ERROR" straight back to "RDS_CONN_CONNECTING"via "rds_tcp_accept_one_path" (e.g. after "rds_tcp_state_change").A subsequent "rds_tcp_reset_callbacks" can then transitionthe state to "RDS_CONN_RESETTING" with a shutdown-worker queued.That'll trip up "rds_conn_init_shutdown", which wasnever adjusted to handle "RDS_CONN_RESETTING" and subsequentlydrops the connection with the dreaded "DR_INV_CONN_STATE",which leaves "RDS_SHUTDOWN_WORK_QUEUED" on forever.So we do two things here:a) Don't shortcut "RDS_CONN_ERROR", but take the longer path through the shutdown code.b) Add "RDS_CONN_RESETTING" to the expected states in "rds_conn_init_shutdown" so that we won't error out and get stuck, if we ever hit weird state transitions like this again."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clocksource/drivers/sh_tmu: Always leave device running after probeThe TMU device can be used as both a clocksource and a clockeventprovider. The driver tries to be smart and power itself on and off, aswell as enabling and disabling its clock when it's not in operation.This behavior is slightly altered if the TMU is used as an earlyplatform device in which case the device is left powered on after probe,but the clock is still enabled and disabled at runtime.This has worked for a long time, but recent improvements in PREEMPT_RTand PROVE_LOCKING have highlighted an issue. As the TMU registers itselfas a clockevent provider, clockevents_register_device(), it needs to useraw spinlocks internally as this is the context of which the clockeventframework interacts with the TMU driver. However in the context ofholding a raw spinlock the TMU driver can't really manage its powerstate or clock with calls to pm_runtime_*() and clk_*() as these callsend up in other platform drivers using regular spinlocks to controlpower and clocks.This mix of spinlock contexts trips a lockdep warning. ============================= [ BUG: Invalid wait context ] 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted ----------------------------- swapper/0/0 is trying to lock: ffff000008c9e180 (&dev->power.lock){-...}-{3:3}, at: __pm_runtime_resume+0x38/0x88 other info that might help us debug this: context-{5:5} 1 lock held by swapper/0/0: ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF400001/0xDCC63000, Driver version 5.0 #0: ffff8000817ec298 ccree e6601000.crypto: ARM ccree device initialized (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_control+0xa4/0x3a8 stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 PREEMPT Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x6c/0x90 dump_stack+0x14/0x1c __lock_acquire+0x904/0x1584 lock_acquire+0x220/0x34c _raw_spin_lock_irqsave+0x58/0x80 __pm_runtime_resume+0x38/0x88 sh_tmu_clock_event_set_oneshot+0x84/0xd4 clockevents_switch_state+0xfc/0x13c tick_broadcast_set_event+0x30/0xa4 __tick_broadcast_oneshot_control+0x1e0/0x3a8 tick_broadcast_oneshot_control+0x30/0x40 cpuidle_enter_state+0x40c/0x680 cpuidle_enter+0x30/0x40 do_idle+0x1f4/0x280 cpu_startup_entry+0x34/0x40 kernel_init+0x0/0x130 do_one_initcall+0x0/0x230 __primary_switched+0x88/0x90For non-PREEMPT_RT builds this is not really an issue, but forPREEMPT_RT builds where normal spinlocks can sleep this might be anissue. Be cautious and always leave the power and clock running afterprobe.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/rds: Clear reconnect pending bitWhen canceling the reconnect worker, care must be taken to reset thereconnect-pending bit. If the reconnect worker has not yet beenscheduled before it is canceled, the reconnect-pending bit will stayon forever.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: radio-keene: fix memory leak in error pathFix a memory leak in usb_keene_probe(). The v4l2 control handler isinitialized and controls are added, but if v4l2_device_register() orvideo_register_device() fails afterward, the handler was never freed,leaking memory.Add v4l2_ctrl_handler_free() call in the err_v4l2 error path to ensurethe control handler is properly freed for all error paths after it isinitialized.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:team: avoid NETDEV_CHANGEMTU event when unregistering slavesyzbot is reporting unregister_netdevice: waiting for netdevsim0 to become free. Usage count = 3 ref_tracker: netdev@ffff88807dcf8618 has 1/2 users at __netdev_tracker_alloc include/linux/netdevice.h:4400 [inline] netdev_hold include/linux/netdevice.h:4429 [inline] inetdev_init+0x201/0x4e0 net/ipv4/devinet.c:286 inetdev_event+0x251/0x1610 net/ipv4/devinet.c:1600 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 call_netdevice_notifiers_mtu net/core/dev.c:2318 [inline] netif_set_mtu_ext+0x5aa/0x800 net/core/dev.c:9886 netif_set_mtu+0xd7/0x1b0 net/core/dev.c:9907 dev_set_mtu+0x126/0x260 net/core/dev_api.c:248 team_port_del+0xb07/0xcb0 drivers/net/team/team_core.c:1333 team_del_slave drivers/net/team/team_core.c:1936 [inline] team_device_event+0x207/0x5b0 drivers/net/team/team_core.c:2929 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2281 [inline] call_netdevice_notifiers net/core/dev.c:2295 [inline] __dev_change_net_namespace+0xcb7/0x2050 net/core/dev.c:12592 do_setlink+0x2ce/0x4590 net/core/rtnetlink.c:3060 rtnl_changelink net/core/rtnetlink.c:3776 [inline] __rtnl_newlink net/core/rtnetlink.c:3935 [inline] rtnl_newlink+0x15a9/0x1be0 net/core/rtnetlink.c:4072 rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894problem. Ido Schimmel found steps to reproduce ip link add name team1 type team ip link add name dummy1 mtu 1499 master team1 type dummy ip netns add ns1 ip link set dev dummy1 netns ns1 ip -n ns1 link del dev dummy1and also found that the same issue was fixed in the bond driver incommit f51048c3e07b ("bonding: avoid NETDEV_CHANGEMTU event whenunregistering slave").Let's do similar thing for the team driver, with commit ad7c7b2172c3 ("net:hold netdev instance lock during sysfs operations") and commit 303a8487a657("net: s/__dev_set_mtu/__netif_set_mtu/") also applied.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after releaseThe atmel_hlcdc_plane_atomic_duplicate_state() callback was copyingthe atmel_hlcdc_plane state structure without properly duplicating thedrm_plane_state. In particular, state->commit remained set to the oldstate commit, which can lead to a use-after-free in the nextdrm_atomic_commit() call.Fix this by calling__drm_atomic_helper_duplicate_plane_state(), which correctly clonesthe base drm_plane_state (including the ->commit pointer).It has been seen when closing and re-opening the device node whileanother DRM client (e.g. fbdev) is still attached:=============================================================================BUG kmalloc-64 (Not tainted): Poison overwritten-----------------------------------------------------------------------------0xc611b344-0xc611b344 @offset=836. First byte 0x6a instead of 0x6bFIX kmalloc-64: Restoring Poison 0xc611b344-0xc611b344=0x6bAllocated in drm_atomic_helper_setup_commit+0x1e8/0x7bc age=178 cpu=0pid=29 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_framebuffer_remove+0x4cc/0x5a8 drm_mode_rmfb_work_fn+0x6c/0x80 process_one_work+0x12c/0x2cc worker_thread+0x2a8/0x400 kthread+0xc0/0xdc ret_from_fork+0x14/0x28Freed in drm_atomic_helper_commit_hw_done+0x100/0x150 age=8 cpu=0pid=169 drm_atomic_helper_commit_hw_done+0x100/0x150 drm_atomic_helper_commit_tail+0x64/0x8c commit_tail+0x168/0x18c drm_atomic_helper_commit+0x138/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54Slab 0xef8bc360 objects=21 used=16 fp=0xc611b7c0flags=0x200(workingset|zone=0)Object 0xc611b340 @offset=832 fp=0xc611b7c0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: fix zero-frag skb in frag_list on partial sendmsg errorSyzkaller reported a warning in kcm_write_msgs() when processing amessage with a zero-fragment skb in the frag_list.When kcm_sendmsg() fills MAX_SKB_FRAGS fragments in the current skb,it allocates a new skb (tskb) and links it into the frag_list beforecopying data. If the copy subsequently fails (e.g. -EFAULT fromuser memory), tskb remains in the frag_list with zero fragments: head skb (msg being assembled, NOT yet in sk_write_queue) +-----------+ | frags[17] | (MAX_SKB_FRAGS, all filled with data) | frag_list-+--> tskb +-----------+ +----------+ | frags[0] | (empty! copy failed before filling) +----------+For SOCK_SEQPACKET with partial data already copied, the error pathsaves this message via partial_message for later completion. ForSOCK_SEQPACKET, sock_write_iter() automatically sets MSG_EOR, so asubsequent zero-length write(fd, NULL, 0) completes the message andqueues it to sk_write_queue. kcm_write_msgs() then walks thefrag_list and hits: WARN_ON(!skb_shinfo(skb)->nr_frags)TCP has a similar pattern where skbs are enqueued before data copyand cleaned up on failure via tcp_remove_empty_skb(). KCM wasmissing the equivalent cleanup.Fix this by tracking the predecessor skb (frag_prev) when allocatinga new frag_list entry. On error, if the tail skb has zero frags,use frag_prev to unlink and free it in O(1) without walking thesingly-linked frag_list. frag_prev is safe to dereference becausethe entire message chain is only held locally (or in kcm->seq_skb)and is not added to sk_write_queue until MSG_EOR, so the send pathcannot free it underneath us.Also change the WARN_ON to WARN_ON_ONCE to avoid flooding the logif the condition is somehow hit repeatedly.There are currently no KCM selftests in the kernel tree; a simplereproducer is available at [1].[1] https://gist.github.com/mrpre/a94d431c757e8d6f168f4dd1a3749daa
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c/tw9906: Fix potential memory leak in tw9906_probe()In one of the error paths in tw9906_probe(), the memory allocated inv4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix thatby calling v4l2_ctrl_handler_free() on the handler in that 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: cx88: Add missing unmap in snd_cx88_hw_params()In error path, add cx88_alsa_dma_unmap() to releaseresource acquired by cx88_alsa_dma_map().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: Add support for TSV110 Spectre-BHB mitigationThe TSV110 processor is vulnerable to the Spectre-BHB (Branch HistoryBuffer) attack, which can be exploited to leak information throughbranch prediction side channels. This commit adds the MIDR of TSV110to the list for software mitigation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: fiemap page fault fixIn gfs2_fiemap(), we are calling iomap_fiemap() while holding the inodeglock. This can lead to recursive glock taking if the fiemap buffer ismemory mapped to the same inode and accessing it triggers a page fault.Fix by disabling page faults for iomap_fiemap() and faulting in thebuffer by hand if necessary.Fixes xfstest generic/742.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mtk-mdp: Fix a reference leak bug in mtk_mdp_remove()In mtk_mdp_probe(), vpu_get_plat_device() increases the referencecount of the returned platform device. Add platform_device_put()to prevent reference 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: supply snapshot context in ceph_zero_partial_object()The ceph_zero_partial_object function was missing proper snapshotcontext for its OSD write operations, which could lead to datainconsistencies in snapshots.Reproducer:../src/vstart.sh --new -x --localhost --bluestore./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a'mount -t ceph fs_a@.a=/ /mnt/mycephfs/ -o conf=./ceph.confdd if=/dev/urandom of=/mnt/mycephfs/foo bs=64K count=1mkdir /mnt/mycephfs/.snap/snap1md5sum /mnt/mycephfs/.snap/snap1/foofallocate -p -o 0 -l 4096 /mnt/mycephfs/fooecho 3 > /proc/sys/vm/drop/cachesmd5sum /mnt/mycephfs/.snap/snap1/foo # get different md5sum!!
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Flush exception handling work when RPM level is zeroEnsure that the exception event handling work is explicitly flushed duringsuspend when the runtime power management level is set to UFS_PM_LVL_0.When the RPM level is zero, the device power mode and link state bothremain active. Previously, the UFS core driver bypassed flushing exceptionevent handling jobs in this configuration. This created a race conditionwhere the driver could attempt to access the host controller to handle anexception after the system had already entered a deep power-down state,resulting in a system crash.Explicitly flush this work and disable auto BKOPs before the suspendcallback proceeds. This guarantees that pending exception tasks completeand prevents illegal hardware access during the power-down sequence.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:APEI/GHES: ensure that won't go past CPER allocated recordThe logic at ghes_new() prevents allocating too large records, bychecking if they're bigger than GHES_ESTATUS_MAX_SIZE (currently, 64KB).Yet, the allocation is done with the actual number of pages from theCPER bios table location, which can be smaller.Yet, a bad firmware could send data with a different size, which mightbe bigger than the allocated memory, causing an OOPS: Unable to handle kernel paging request at virtual address fff00000f9b40000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 52-bit VAs, pgdp=000000008ba16000 [fff00000f9b40000] pgd=180000013ffff403, p4d=180000013fffe403, pud=180000013f85b403, pmd=180000013f68d403, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 303 Comm: kworker/0:1 Not tainted 6.19.0-rc1-00002-gda407d200220 #34 PREEMPT Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022 Workqueue: kacpi_notify acpi_os_execute_deferred pstate: 214020c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : hex_dump_to_buffer+0x30c/0x4a0 lr : hex_dump_to_buffer+0x328/0x4a0 sp : ffff800080e13880 x29: ffff800080e13880 x28: ffffac9aba86f6a8 x27: 0000000000000083 x26: fff00000f9b3fffc x25: 0000000000000004 x24: 0000000000000004 x23: ffff800080e13905 x22: 0000000000000010 x21: 0000000000000083 x20: 0000000000000001 x19: 0000000000000008 x18: 0000000000000010 x17: 0000000000000001 x16: 00000007c7f20fec x15: 0000000000000020 x14: 0000000000000008 x13: 0000000000081020 x12: 0000000000000008 x11: ffff800080e13905 x10: ffff800080e13988 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000001 x6 : 0000000000000020 x5 : 0000000000000030 x4 : 00000000fffffffe x3 : 0000000000000000 x2 : ffffac9aba78c1c8 x1 : ffffac9aba76d0a8 x0 : 0000000000000008 Call trace: hex_dump_to_buffer+0x30c/0x4a0 (P) print_hex_dump+0xac/0x170 cper_estatus_print_section+0x90c/0x968 cper_estatus_print+0xf0/0x158 __ghes_print_estatus+0xa0/0x148 ghes_proc+0x1bc/0x220 ghes_notify_hed+0x5c/0xb8 notifier_call_chain+0x78/0x148 blocking_notifier_call_chain+0x4c/0x80 acpi_hed_notify+0x28/0x40 acpi_ev_notify_dispatch+0x50/0x80 acpi_os_execute_deferred+0x24/0x48 process_one_work+0x15c/0x3b0 worker_thread+0x2d0/0x400 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: 6b14033f 540001ad a94707e2 f100029f (b8747b44) ---[ end trace 0000000000000000 ]---Prevent that by taking the actual allocated are into account whenchecking for CPER length.[ rjw: Subject tweaks ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Add sanity check for OOB writes at silencingAt silencing the playback URB packets in the implicit fb mode beforethe actual playback, we blindly assume that the received packets fitwith the buffer size. But when the setup in the capture streamdiffers from the playback stream (e.g. due to the USB core limitationof max packet size), such an inconsistency may lead to OOB writes tothe buffer, resulting in a crash.For addressing it, add a sanity check of the transfer buffer size atprepare_silent_urb(), and stop the data copy if the received dataoverflows. Also, report back the transfer error properly from there,too.Note that this doesn't fix the root cause of the playback erroritself, but this merely covers the kernel Oops.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mailbox: Prevent out-of-bounds access in fw_mbox_index_xlate()Although it is guided that `#mbox-cells` must be at least 1, there aremany instances of `#mbox-cells = <0>;` in the device tree. If that isthe case and the corresponding mailbox controller does not provide`fw_xlate` and of_xlate` function pointers, `fw_mbox_index_xlate()` willbe used by default and out-of-bounds accesses could occur due to lack ofbounds check in that 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: ec_bhf: Fix dma_free_coherent() dma handledma_free_coherent() in error path takes priv->rx_buf.alloc_len asthe dma handle. This would lead to improper unmapping of the buffer.Change the dma handle to priv->rx_buf.alloc_phys.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: Account property blob allocations to memcgDRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sizedproperty blobs backed by kernel memory.Currently, the blob data allocation is not accounted to the allocatingprocess's memory cgroup, allowing unprivileged users to trigger unboundedkernel memory consumption and potentially cause system-wide OOM.Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memoryis properly charged to the caller's memcg. This ensures existing cgroupmemory limits apply and prevents uncontrolled kernel memory growth withoutintroducing additional policy or per-file limits.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: move ext4_percpu_param_init() before ext4_mb_init()When running `kvm-xfstests -c ext4/1k -C 1 generic/383` with the`DOUBLE_CHECK` macro defined, the following panic is triggered:==================================================================EXT4-fs error (device vdc): ext4_validate_block_bitmap:423: comm mount: bg 0: bad block bitmap checksumBUG: unable to handle page fault for address: ff110000fa2cc000PGD 3e01067 P4D 3e02067 PUD 0Oops: Oops: 0000 [#1] SMP NOPTICPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none)RIP: 0010:percpu_counter_add_batch+0x13/0xa0Call Trace: ext4_mark_group_bitmap_corrupted+0xcb/0xe0 ext4_validate_block_bitmap+0x2a1/0x2f0 ext4_read_block_bitmap+0x33/0x50 mb_group_bb_bitmap_alloc+0x33/0x80 ext4_mb_add_groupinfo+0x190/0x250 ext4_mb_init_backend+0x87/0x290 ext4_mb_init+0x456/0x640 __ext4_fill_super+0x1072/0x1680 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4f6/0x6b0 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e==================================================================This issue can be reproduced using the following commands: mkfs.ext4 -F -q -b 1024 /dev/sda 5G tune2fs -O quota,project /dev/sda mount /dev/sda /tmp/testWith DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() readsand validates the block bitmap. When the validation fails,ext4_mark_group_bitmap_corrupted() attempts to updatesbi->s_freeclusters_counter. However, this percpu_counter has not beeninitialized yet at this point, which leads to the panic described above.Fix this by moving the execution of ext4_percpu_param_init() to occurbefore ext4_mb_init(), ensuring the per-CPU counters are initializedbefore they are 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: replace rio_free_net() with kfree() in rio_scan_alloc_net()When idtab allocation fails, net is not registered with rio_add_net() yet,so kfree(net) is sufficient to release the memory. Set mport->net to NULLto avoid dangling pointer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not ASSERT() when the fs flips RO inside btrfs_repair_io_failure()[BUG]There is a bug report that when btrfs hits ENOSPC error in a criticalpath, btrfs flips RO (this part is expected, although the ENOSPC bugstill needs to be addressed).The problem is after the RO flip, if there is a read repair pending, wecan hit the ASSERT() inside btrfs_repair_io_failure() like the following: BTRFS info (device vdc): relocating block group 30408704 flags metadata|raid1 ------------[ cut here ]------------ BTRFS: Transaction aborted (error -28) WARNING: fs/btrfs/extent-tree.c:3235 at __btrfs_free_extent.isra.0+0x453/0xfd0, CPU#1: btrfs/383844 Modules linked in: kvm_intel kvm irqbypass [...] ---[ end trace 0000000000000000 ]--- BTRFS info (device vdc state EA): 2 enospc errors during balance BTRFS info (device vdc state EA): balance: ended with status: -30 BTRFS error (device vdc state EA): parent transid verify failed on logical 30556160 mirror 2 wanted 8 found 6 BTRFS error (device vdc state EA): bdev /dev/nvme0n1 errs: wr 0, rd 0, flush 0, corrupt 10, gen 0 [...] assertion failed: !(fs_info->sb->s_flags & SB_RDONLY) :: 0, in fs/btrfs/bio.c:938 ------------[ cut here ]------------ assertion failed: !(fs_info->sb->s_flags & SB_RDONLY) :: 0, in fs/btrfs/bio.c:938 kernel BUG at fs/btrfs/bio.c:938! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 868 Comm: kworker/u8:13 Tainted: G W N 6.19.0-rc6+ #4788 PREEMPT(full) Tainted: [W]=WARN, [N]=TEST Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 Workqueue: btrfs-endio simple_end_io_work RIP: 0010:btrfs_repair_io_failure.cold+0xb2/0x120 RSP: 0000:ffffc90001d2bcf0 EFLAGS: 00010246 RAX: 0000000000000051 RBX: 0000000000001000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8305cf42 RDI: 00000000ffffffff RBP: 0000000000000002 R08: 00000000fffeffff R09: ffffffff837fa988 R10: ffffffff8327a9e0 R11: 6f69747265737361 R12: ffff88813018d310 R13: ffff888168b8a000 R14: ffffc90001d2bd90 R15: ffff88810a169000 FS: 0000000000000000(0000) GS:ffff8885e752c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 ------------[ cut here ]------------[CAUSE]The cause of -ENOSPC error during the test case btrfs/124 is stillunknown, although it's known that we still have cases where metadata canbe over-committed but can not be fulfilled correctly, thus if we hitsuch ENOSPC error inside a critical path, we have no choice but abortthe current transaction.This will mark the fs read-only.The problem is inside the btrfs_repair_io_failure() path that we requirethe fs not to be mount read-only. This is normally fine, but if we aredoing a read-repair meanwhile the fs flips RO due to a critical error,we can enter btrfs_repair_io_failure() with super block set toread-only, thus triggering the above crash.[FIX]Just replace the ASSERT() with a proper return if the fs is alreadyread-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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Set DMA segment size to avoid debug warningsWhen using V3D rendering with CONFIG_DMA_API_DEBUG enabled, thekernel occasionally reports a segment size mismatch. This is because'max_seg_size' is not set. The kernel defaults to 64K. setting'max_seg_size' to the maximum will prevent 'debug_dma_map_sg()'from complaining about the over-mapping of the V3D segment length.DMA-API: v3d 1002000000.v3d: mapping sg segment longer than device claims to support [len=8290304] [max=65536]WARNING: CPU: 0 PID: 493 at kernel/dma/debug.c:1179 debug_dma_map_sg+0x330/0x388CPU: 0 UID: 0 PID: 493 Comm: Xorg Not tainted 6.12.53-yocto-standard #1Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : debug_dma_map_sg+0x330/0x388lr : debug_dma_map_sg+0x330/0x388sp : ffff8000829a3ac0x29: ffff8000829a3ac0 x28: 0000000000000001 x27: ffff8000813fe000x26: ffffc1ffc0000000 x25: ffff00010fdeb760 x24: 0000000000000000x23: ffff8000816a9bf0 x22: 0000000000000001 x21: 0000000000000002x20: 0000000000000002 x19: ffff00010185e810 x18: ffffffffffffffffx17: 69766564206e6168 x16: 74207265676e6f6c x15: 20746e656d676573x14: 20677320676e6970 x13: 5d34303334393134 x12: 0000000000000000x11: 00000000000000c0 x10: 00000000000009c0 x9 : ffff8000800e0b7cx8 : ffff00010a315ca0 x7 : ffff8000816a5110 x6 : 0000000000000001x5 : 000000000000002b x4 : 0000000000000002 x3 : 0000000000000008x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00010a315280Call trace: debug_dma_map_sg+0x330/0x388 __dma_map_sg_attrs+0xc0/0x278 dma_map_sgtable+0x30/0x58 drm_gem_shmem_get_pages_sgt+0xb4/0x140 v3d_bo_create_finish+0x28/0x130 [v3d] v3d_create_bo_ioctl+0x54/0x180 [v3d] drm_ioctl_kernel+0xc8/0x140 drm_ioctl+0x2d4/0x4d8
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't BUG() on unexpected delayed ref type in run_one_delayed_ref()There is no need to BUG(), we can just return an error and log an errormessage.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md raid: fix hang when stopping arrays with metadata through dm-raidWhen using device-mapper's dm-raid target, stopping a RAID array can causethe system to hang under specific conditions.This occurs when:- A dm-raid managed device tree is suspended from top to bottom (the top-level RAID device is suspended first, followed by its underlying metadata and data devices)- The top-level RAID device is then removedRemoving the top-level device triggers a hang in the following sequence:the dm-raid destructor calls md_stop(), which tries to flush thewrite-intent bitmap by writing to the metadata sub-devices. However, thesedevices are already suspended, making them unable to complete the write-intentoperations and causing an indefinite block.Fix:- Prevent bitmap flushing when md_stop() is called from dm-raiddestructor context and avoid a quiescing/unquescing cycle which could also cause I/O- Still allow write-intent bitmap flushing when called from dm-raidsuspend contextThis ensures that RAID array teardown can complete successfully even when theunderlying devices are in a suspended state.This second patch uses md_is_rdwr() to distinguish between suspend anddestructor paths as elaborated on above.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4()In acpi_processor_errata_piix4(), the pointer dev is first assigned an IDEdevice and then reassigned an ISA device: dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB, ...); dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB_0, ...);If the first lookup succeeds but the second fails, dev becomes NULL. Thisleads to a potential null-pointer dereference when dev_dbg() is called: if (errata.piix4.bmisx) dev_dbg(&dev->dev, ...);To prevent this, use two temporary pointers and retrieve each deviceindependently, avoiding overwriting dev with a possible NULL value.[ rjw: Subject adjustment, added an empty code line ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm: remove fake timeout to avoid leak requestSince commit 15f73f5b3e59 ("blk-mq: move failure injection out ofblk_mq_complete_request"), drivers are responsible for callingblk_should_fake_timeout() at appropriate code paths and opportunities.However, the dm driver does not implement its own timeout handler andrelies on the timeout handling of its slave devices.If an io-timeout-fail error is injected to a dm device, the requestwill be leaked and never completed, causing tasks to hang indefinitely.Reproduce:1. prepare dm which has iscsi slave device2. inject io-timeout-fail to dm echo 1 >/sys/class/block/dm-0/io-timeout-fail echo 100 >/sys/kernel/debug/fail_io_timeout/probability echo 10 >/sys/kernel/debug/fail_io_timeout/times3. read/write dm4. iscsiadm -m node -uResult: hang task like below[ 862.243768] INFO: task kworker/u514:2:151 blocked for more than 122 seconds.[ 862.244133] Tainted: G E 6.19.0-rc1+ #51[ 862.244337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.[ 862.244718] task:kworker/u514:2 state:D stack:0 pid:151 tgid:151 ppid:2 task_flags:0x4288060 flags:0x00080000[ 862.245024] Workqueue: iscsi_ctrl_3:1 __iscsi_unbind_session [scsi_transport_iscsi][ 862.245264] Call Trace:[ 862.245587] [ 862.245814] __schedule+0x810/0x15c0[ 862.246557] schedule+0x69/0x180[ 862.246760] blk_mq_freeze_queue_wait+0xde/0x120[ 862.247688] elevator_change+0x16d/0x460[ 862.247893] elevator_set_none+0x87/0xf0[ 862.248798] blk_unregister_queue+0x12e/0x2a0[ 862.248995] __del_gendisk+0x231/0x7e0[ 862.250143] del_gendisk+0x12f/0x1d0[ 862.250339] sd_remove+0x85/0x130 [sd_mod][ 862.250650] device_release_driver_internal+0x36d/0x530[ 862.250849] bus_remove_device+0x1dd/0x3f0[ 862.251042] device_del+0x38a/0x930[ 862.252095] __scsi_remove_device+0x293/0x360[ 862.252291] scsi_remove_target+0x486/0x760[ 862.252654] __iscsi_unbind_session+0x18a/0x3e0 [scsi_transport_iscsi][ 862.252886] process_one_work+0x633/0xe50[ 862.253101] worker_thread+0x6df/0xf10[ 862.253647] kthread+0x36d/0x720[ 862.254533] ret_from_fork+0x2a6/0x470[ 862.255852] ret_from_fork_asm+0x1a/0x30[ 862.256037] Remove the blk_should_fake_timeout() check from dm, as dm has nonative timeout handling and should not attempt to fake timeouts.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: governor: fix double free in cpufreq_dbs_governor_init() error pathWhen kobject_init_and_add() fails, cpufreq_dbs_governor_init() callskobject_put(&dbs_data->attr_set.kobj).The kobject release callback cpufreq_dbs_data_release() callsgov->exit(dbs_data) and kfree(dbs_data), but the current error paththen calls gov->exit(dbs_data) and kfree(dbs_data) again, causing adouble free.Keep the direct kfree(dbs_data) for the gov->init() failure path, butafter kobject_init_and_add() has been called, let kobject_put() handlethe cleanup through cpufreq_dbs_data_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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: prevent possible UaF in addrconf_permanent_addr()The mentioned helper try to warn the user about an exceptionalcondition, but the message is delivered too late, accessing the ipv6after its possible deletion.Reorder the statement to avoid the possible UaF; while at it, place thewarning outside the idev->lock as it needs no protection.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_subset: Fix unbalanced refcnt in geth_freegeth_alloc() increments the reference count, but geth_free() fails todecrement it. This prevents the configuration of attributes via configfsafter unlinking the function.Decrement the reference count in geth_free() to ensure proper cleanup.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: bh1780: fix PM runtime leak on error pathMove pm_runtime_put_autosuspend() before the error check to ensurethe PM runtime reference count is always decremented afterpm_runtime_get_sync(), regardless of whether the read operationsucceeds or 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/apic: Disable x2apic on resume if the kernel expects soWhen resuming from s2ram, firmware may re-enable x2apic mode, which may havebeen disabled by the kernel during boot either because it doesn't support IRQremapping or for other reasons. This causes the kernel to continue using thexapic interface, while the hardware is in x2apic mode, which causes hangs.This happens on defconfig + bare metal + s2ram.Fix this in lapic_resume() by disabling x2apic if the kernel expects it to bedisabled, i.e. when x2apic_mode = 0.The ACPI v6.6 spec, Section 16.3 [1] says firmware restores either thepre-sleep configuration or initial boot configuration for each CPU, includingMSR state: When executing from the power-on reset vector as a result of waking from an S2 or S3 sleep state, the platform firmware performs only the hardware initialization required to restore the system to either the state the platform was in prior to the initial operating system boot, or to the pre-sleep configuration state. In multiprocessor systems, non-boot processors should be placed in the same state as prior to the initial operating system boot. (further ahead) If this is an S2 or S3 wake, then the platform runtime firmware restores minimum context of the system before jumping to the waking vector. This includes: CPU configuration. Platform runtime firmware restores the pre-sleep configuration or initial boot configuration of each CPU (MSR, MTRR, firmware update, SMBase, and so on). Interrupts must be disabled (for IA-32 processors, disabled by CLI instruction). (and other things)So at least as per the spec, re-enablement of x2apic by the firmware isallowed if "x2apic on" is a part of the initial boot configuration. [1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization [ bp: Massage. ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix use-after-free race in VM acquireReplace non-atomic vm->process_info assignment with cmpxchg()to prevent race when parent/child processes sharing a drm_fileboth try to acquire the same VM after fork().(cherry picked from commit c7c573275ec20db05be769288a3e3bb2250ec618)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ncsi: fix skb leak in error pathsEarly return paths in NCSI RX and AEN handlers fail to releasethe received skb, resulting in a memory leak.Specifically, ncsi_aen_handler() returns on invalid AEN packetswithout consuming the skb. Similarly, ncsi_rcv_rsp() exits earlywhen failing to resolve the NCSI device, response handler, orrequest, leaving the skb unfreed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nouveau/dpcd: return EBUSY for aux xfer if the device is asleepIf we have runtime suspended, and userspace wants to use /dev/drm_dp_*then just tell it the device is busy instead of crashing in the GSPcode.WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy)Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]This is a simple fix to get backported. We should probably engineer aproper power domain solution to wake up devices and keep them awakewhile fw updates are happening.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/tcp-md5: Fix MAC comparison to be constant-timeTo prevent timing attacks, MACs need to be compared in constanttime. Use the appropriate helper function for 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ieThe current code checks 'i + 5 < in_len' at the end of the if statement.However, it accesses 'in_ie[i + 5]' before that check, which can leadto an out-of-bounds read. Move the length check to the beginning of theconditional to ensure the index is within bounds before accessing thearray.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: properly validate the data in rtw_get_ie_ex()Just like in commit 154828bf9559 ("staging: rtl8723bs: fix out-of-boundsread in rtw_get_ie() parser"), we don't trust the data in the frame sowe should check the length better before acting on 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kprobes: avoid crash when rmmod/insmod after ftrace killedAfter we hit ftrace is killed by some errors, the kernel crash ifwe remove modules in which kprobe probes.BUG: unable to handle page fault for address: fffffbfff805000dPGD 817fcc067 P4D 817fcc067 PUD 817fc8067 PMD 101555067 PTE 0Oops: Oops: 0000 [#1] SMP KASAN PTICPU: 4 UID: 0 PID: 2012 Comm: rmmod Tainted: G W OETainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULERIP: 0010:kprobes_module_callback+0x89/0x790RSP: 0018:ffff88812e157d30 EFLAGS: 00010a02RAX: 1ffffffff805000d RBX: dffffc0000000000 RCX: ffffffff86a8de90RDX: ffffed1025c2af9b RSI: 0000000000000008 RDI: ffffffffc0280068RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed1025c2af9aR10: ffff88812e157cd7 R11: 205d323130325420 R12: 0000000000000002R13: ffffffffc0290488 R14: 0000000000000002 R15: ffffffffc0280040FS: 00007fbc450dd740(0000) GS:ffff888420331000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: fffffbfff805000d CR3: 000000010f624000 CR4: 00000000000006f0Call Trace: notifier_call_chain+0xc6/0x280 blocking_notifier_call_chain+0x60/0x90 __do_sys_delete_module.constprop.0+0x32a/0x4e0 do_syscall_64+0x5d/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThis is because the kprobe on ftrace does not correctly handlesthe kprobe_ftrace_disabled flag set by ftrace_kill().To prevent this error, check kprobe_ftrace_disabled in__disarm_kprobe_ftrace() and skip all ftrace related 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Fix NULL pointer exception during user_scan()user_scan() invokes updated sas_user_scan() for channel 0, and ifsuccessful, iteratively scans remaining channels (1 to shost->max_channel)via scsi_scan_host_selected() in commit 37c4e72b0651 ("scsi: Fixsas_user_scan() to handle wildcard and multi-channel scans"). However,hisi_sas supports only one channel, and the current value of max_channel is1. sas_user_scan() for channel 1 will trigger the following NULL pointerexception:[ 441.554662] Unable to handle kernel NULL pointer dereference at virtual address 00000000000008b0[ 441.554699] Mem abort info:[ 441.554710] ESR = 0x0000000096000004[ 441.554718] EC = 0x25: DABT (current EL), IL = 32 bits[ 441.554723] SET = 0, FnV = 0[ 441.554726] EA = 0, S1PTW = 0[ 441.554730] FSC = 0x04: level 0 translation fault[ 441.554735] Data abort info:[ 441.554737] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 441.554742] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 441.554747] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 441.554752] user pgtable: 4k pages, 48-bit VAs, pgdp=00000828377a6000[ 441.554757] [00000000000008b0] pgd=0000000000000000, p4d=0000000000000000[ 441.554769] Internal error: Oops: 0000000096000004 [#1] SMP[ 441.629589] Modules linked in: arm_spe_pmu arm_smmuv3_pmu tpm_tis_spi hisi_uncore_sllc_pmu hisi_uncore_pa_pmu hisi_uncore_l3c_pmu hisi_uncore_hha_pmu hisi_uncore_ddrc_pmu hisi_uncore_cpa_pmu hns3_pmu hisi_ptt hisi_pcie_pmu tpm_tis_core spidev spi_hisi_sfc_v3xx hisi_uncore_pmu spi_dw_mmio fuse hclge hclge_common hisi_sec2 hisi_hpre hisi_zip hisi_qm hns3 hisi_sas_v3_hw sm3_ce sbsa_gwdt hnae3 hisi_sas_main uacce hisi_dma i2c_hisi dm_mirror dm_region_hash dm_log dm_mod[ 441.670819] CPU: 46 UID: 0 PID: 6994 Comm: bash Kdump: loaded Not tainted 7.0.0-rc2+ #84 PREEMPT[ 441.691327] pstate: 81400009 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)[ 441.698277] pc : sas_find_dev_by_rphy+0x44/0x118[ 441.702896] lr : sas_find_dev_by_rphy+0x3c/0x118[ 441.707502] sp : ffff80009abbba40[ 441.710805] x29: ffff80009abbba40 x28: ffff082819a40008 x27: ffff082810c37c08[ 441.717930] x26: ffff082810c37c28 x25: ffff082819a40290 x24: ffff082810c37c00[ 441.725054] x23: 0000000000000000 x22: 0000000000000001 x21: ffff082819a40000[ 441.732179] x20: ffff082819a40290 x19: 0000000000000000 x18: 0000000000000020[ 441.739304] x17: 0000000000000000 x16: ffffb5dad6bda690 x15: 00000000ffffffff[ 441.746428] x14: ffff082814c3b26c x13: 00000000ffffffff x12: ffff082814c3b26a[ 441.753553] x11: 00000000000000c0 x10: 000000000000003a x9 : ffffb5dad5ea94f4[ 441.760678] x8 : 000000000000003a x7 : ffff80009abbbab0 x6 : 0000000000000030[ 441.767802] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000[ 441.774926] x2 : ffff08280f35a300 x1 : ffffb5dad7127180 x0 : 0000000000000000[ 441.782053] Call trace:[ 441.784488] sas_find_dev_by_rphy+0x44/0x118 (P)[ 441.789095] sas_target_alloc+0x24/0xb0[ 441.792920] scsi_alloc_target+0x290/0x330[ 441.797010] __scsi_scan_target+0x88/0x258[ 441.801096] scsi_scan_channel+0x74/0xb8[ 441.805008] scsi_scan_host_selected+0x170/0x188[ 441.809615] sas_user_scan+0xfc/0x148[ 441.813267] store_scan+0x10c/0x180[ 441.816743] dev_attr_store+0x20/0x40[ 441.820398] sysfs_kf_write+0x84/0xa8[ 441.824054] kernfs_fop_write_iter+0x130/0x1c8[ 441.828487] vfs_write+0x2c0/0x370[ 441.831880] ksys_write+0x74/0x118[ 441.835271] __arm64_sys_write+0x24/0x38[ 441.839182] invoke_syscall+0x50/0x120[ 441.842919] el0_svc_common.constprop.0+0xc8/0xf0[ 441.847611] do_el0_svc+0x24/0x38[ 441.850913] el0_svc+0x38/0x158[ 441.854043] el0t_64_sync_handler+0xa0/0xe8[ 441.858214] el0t_64_sync+0x1ac/0x1b0[ 441.861865] Code: aa1303e0 97ff70a8 34ffff80 d10a4273 (f9445a75)[ 441.867946] ---[ end trace 0000000000000000 ]---Therefore---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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc, perf: Check that current->mm is alive before getting user callchainIt may happen that mm is already released, which leads to kernel panic.This adds the NULL check for current->mm, similarly tocommit 20afc60f892d ("x86, perf: Check that current->mm is alive before getting user callchain").I was getting this panic when running a profiling BPF program(profile.py from bcc-tools): [26215.051935] Kernel attempted to read user page (588) - exploit attempt? (uid: 0) [26215.051950] BUG: Kernel NULL pointer dereference on read at 0x00000588 [26215.051952] Faulting instruction address: 0xc00000000020fac0 [26215.051957] Oops: Kernel access of bad area, sig: 11 [#1] [...] [26215.052049] Call Trace: [26215.052050] [c000000061da6d30] [c00000000020fc10] perf_callchain_user_64+0x2d0/0x490 (unreliable) [26215.052054] [c000000061da6dc0] [c00000000020f92c] perf_callchain_user+0x1c/0x30 [26215.052057] [c000000061da6de0] [c0000000005ab2a0] get_perf_callchain+0x100/0x360 [26215.052063] [c000000061da6e70] [c000000000573bc8] bpf_get_stackid+0x88/0xf0 [26215.052067] [c000000061da6ea0] [c008000000042258] bpf_prog_16d4ab9ab662f669_do_perf_event+0xf8/0x274 [...]In addition, move storing the top-level stack entry to genericperf_callchain_user to make sure the top-evel entry is always captured,even if current->mm is NULL.[Maddy: fixed message to avoid checkpatch format style 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: image: mdc800: kill download URB on timeoutmdc800_device_read() submits download_urb and waits for completion.If the timeout fires and the device has not responded, the functionreturns without killing the URB, leaving it active.A subsequent read() resubmits the same URB while it is stillin-flight, triggering the WARN in usb_submit_urb(): "URB submitted while active"Check the return value of wait_event_timeout() and kill the URB ifit indicates timeout, ensuring the URB is complete before its statusis inspected or the URB is resubmitted.Similar to- commit 372c93131998 ("USB: yurex: fix control-URB timeout handling")- commit b98d5000c505 ("media: rc: iguanair: handle timeouts")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: renesas_usbhs: fix use-after-free in ISR during device removalIn usbhs_remove(), the driver frees resources (including the pipe array)while the interrupt handler (usbhs_interrupt) is still registered. If aninterrupt fires after usbhs_pipe_remove() but before the driver is fullyunbound, the ISR may access freed memory, causing a use-after-free.Fix this by calling devm_free_irq() before freeing resources. This ensuresthe interrupt handler is both disabled and synchronized (waits for anyrunning ISR to complete) before usbhs_pipe_remove() is 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: class: cdc-wdm: fix reordering issue in read code pathQuoting the bug report:Due to compiler optimization or CPU out-of-order execution, thedesc->length update can be reordered before the memmove. If thishappens, wdm_read() can see the new length and call copy_to_user() onuninitialized memory. This also violates LKMM data race rules [1].Fix it by using WRITE_ONCE and memory barriers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:e1000/e1000e: Fix leak in DMA error cleanupIf an error is encountered while mapping TX buffers, the driver shouldunmap any buffers already mapped for that skb.Because count is incremented after a successful mapping, it will alwaysmatch the correct number of unmappings needed when dma_error is reached.Decrementing count before the while loop in dma_error causes anoff-by-one error. If any mapping was successful before an unsuccessfulmapping, exactly one DMA mapping would leak.In these commits, a faulty while condition caused an infinite loop indma_error:Commit 03b1320dfcee ("e1000e: remove use of skb_dma_map from e1000edriver")Commit 602c0554d7b0 ("e1000: remove use of skb_dma_map from e1000 driver")Commit c1fa347f20f1 ("e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests ofunsigned in *_tx_map()") fixed the infinite loop, but introduced theoff-by-one error.This issue may still exist in the igbvf driver, but I did not address itin this 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: Fix slab-out-of-bounds in nvme_dbbuf_setdev->online_queues is a count incremented in nvme_init_queue. Thus,valid indices are 0 through dev->online_queues − 1.This patch fixes the loop condition to ensure the index stays within thevalid range. Index 0 is excluded because it is the admin queue.KASAN splat:==================================================================BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline]BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404Read of size 2 at addr ffff88800592a574 by task kworker/u8:5/74CPU: 0 UID: 0 PID: 74 Comm: kworker/u8:5 Not tainted 6.19.0-dirty #10 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014Workqueue: nvme-reset-wq nvme_reset_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xea/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xce/0x5d0 mm/kasan/report.c:482 kasan_report+0xdc/0x110 mm/kasan/report.c:595 __asan_report_load2_noabort+0x18/0x20 mm/kasan/report_generic.c:379 nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline] nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404 nvme_reset_work+0x36b/0x8c0 drivers/nvme/host/pci.c:3252 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 Allocated by task 34 on cpu 1 at 4.241550s: kasan_save_stack+0x2c/0x60 mm/kasan/common.c:57 kasan_save_track+0x1c/0x70 mm/kasan/common.c:78 kasan_save_alloc_info+0x3c/0x50 mm/kasan/generic.c:570 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xb5/0xc0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5657 [inline] __kmalloc_node_noprof+0x2bf/0x8d0 mm/slub.c:5663 kmalloc_array_node_noprof include/linux/slab.h:1075 [inline] nvme_pci_alloc_dev drivers/nvme/host/pci.c:3479 [inline] nvme_probe+0x2f1/0x1820 drivers/nvme/host/pci.c:3534 local_pci_probe+0xef/0x1c0 drivers/pci/pci-driver.c:324 pci_call_probe drivers/pci/pci-driver.c:392 [inline] __pci_device_probe drivers/pci/pci-driver.c:417 [inline] pci_device_probe+0x743/0x920 drivers/pci/pci-driver.c:451 call_driver_probe drivers/base/dd.c:583 [inline] really_probe+0x29b/0xb70 drivers/base/dd.c:661 __driver_probe_device+0x3b0/0x4a0 drivers/base/dd.c:803 driver_probe_device+0x56/0x1f0 drivers/base/dd.c:833 __driver_attach_async_helper+0x155/0x340 drivers/base/dd.c:1159 async_run_entry_fn+0xa6/0x4b0 kernel/async.c:129 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246The buggy address belongs to the object at ffff88800592a000 which belongs to the cache kmalloc-2k of size 2048The buggy address is located 244 bytes to the right of allocated 1152-byte region [ffff88800592a000, ffff88800592a480)The buggy address belongs to the physical page:page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5928head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0anon flags: 0xfffffc0000040(head|node=0|zone=1|lastcpupid=0x1fffff)page_type: f5(slab)raw: 000fffffc0000040 ffff888001042000 0000000000000000 dead000000000001raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000head: 000fffffc0000040 ffff888001042000 00000---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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table()nfnl_cthelper_dump_table() has a 'goto restart' that jumps to a labelinside the for loop body. When the "last" helper saved in cb->args[1]is deleted between dump rounds, every entry fails the (cur != last)check, so cb->args[1] is never cleared. The for loop finishes withcb->args[0] == nf_ct_helper_hsize, and the 'goto restart' jumps backinto the loop body bypassing the bounds check, causing an 8-byteout-of-bounds read on nf_ct_helper_hash[nf_ct_helper_hsize].The 'goto restart' block was meant to re-traverse the current bucketwhen "last" is no longer found, but it was placed after the for loopinstead of inside it. Move the block into the for loop body so thatthe restart only occurs while cb->args[0] is still within bounds. BUG: KASAN: slab-out-of-bounds in nfnl_cthelper_dump_table+0x9f/0x1b0 Read of size 8 at addr ffff888104ca3000 by task poc_cthelper/131 Call Trace: nfnl_cthelper_dump_table+0x9f/0x1b0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 sock_recvmsg+0xde/0xf0 __sys_recvfrom+0x150/0x200 __x64_sys_recvfrom+0x76/0x90 do_syscall_64+0xc3/0x6e0 Allocated by task 1: __kvmalloc_node_noprof+0x21b/0x700 nf_ct_alloc_hashtable+0x65/0xd0 nf_conntrack_helper_init+0x21/0x60 nf_conntrack_init_start+0x18d/0x300 nf_conntrack_standalone_init+0x12/0xc0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_queue: fix entry leak in bridge verdict error pathnfqnl_recv_verdict() calls find_dequeue_entry() to remove the queueentry from the queue data structures, taking ownership of the entry.For PF_BRIDGE packets, it then calls nfqa_parse_bridge() to parse VLANattributes. If nfqa_parse_bridge() returns an error (e.g. NFQA_VLANpresent but NFQA_VLAN_TCI missing), the function returns immediatelywithout freeing the dequeued entry or its sk_buff.This leaks the nf_queue_entry, its associated sk_buff, and all heldreferences (net_device refcounts, struct net refcount). Repeatedtriggering exhausts kernel memory.Fix this by dropping the entry via nfqnl_reinject() with NF_DROP verdicton the error path, consistent with other error handling in this file.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: x_tables: guard option walkers against 1-byte tail readsWhen the last byte of options is a non-single-byte option kind, walkersthat advance with i += op[i + 1] ? : 1 can read op[i + 1] past the endof the option area.Add an explicit i == optlen - 1 check before dereferencing op[i + 1]in xt_tcpudp and xt_dccp option walkers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: fix type confusion in bond_setup_by_slave()kernel BUG at net/core/skbuff.c:2306!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTIRIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306RSP: 0018:ffffc90004aff760 EFLAGS: 00010293RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0eRDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0Call Trace: ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c:900 dev_hard_header include/linux/netdevice.h:3439 [inline] packet_snd net/packet/af_packet.c:3028 [inline] packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c:3108 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa54/0xc30 net/socket.c:2592 ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646 __sys_sendmsg+0x170/0x220 net/socket.c:2678 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fe1a0e6c1a9When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond,bond_setup_by_slave() directly copies the slave's header_ops to thebond device: bond_dev->header_ops = slave_dev->header_ops;This causes a type confusion when dev_hard_header() is later calledon the bond device. Functions like ipgre_header(), ip6gre_header(),all usenetdev_priv(dev) to access their device-specific private data. Whencalled with the bond device, netdev_priv() returns the bond's privatedata (struct bonding) instead of the expected type (e.g. structip_tunnel), leading to garbage values being read and kernel crashes.Fix this by introducing bond_header_ops with wrapper functions thatdelegate to the active slave's header_ops using the slave's owndevice. This ensures netdev_priv() in the slave's header functionsalways receives the correct device.The fix is placed in the bonding driver rather than individual devicedrivers, as the root cause is bond blindly inheriting header_ops fromthe slave without considering that these callbacks expect a specificnetdev_priv() layout.The type confusion can be observed by adding a printk inipgre_header() and running the following commands: ip link add dummy0 type dummy ip addr add 10.0.0.1/24 dev dummy0 ip link set dummy0 up ip link add gre1 type gre local 10.0.0.1 ip link add bond1 type bond mode active-backup ip link set gre1 master bond1 ip link set gre1 up ip link set bond1 up ip addr add fe80::1/64 dev bond1
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: caif: hold tty->link reference in ldisc_open and ser_releaseA reproducer triggers a KASAN slab-use-after-free in pty_write_room()when caif_serial's TX path calls tty_write_room(). The faulting accessis on tty->link->port.Hold an extra kref on tty->link for the lifetime of the caif_serial linediscipline: get it in ldisc_open() and drop it in ser_release(), andalso drop it on the ldisc_open() error path.With this change applied, the reproducer no longer triggers the UAF inmy testing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix DMA FIFO desync on error CQE SQ recoveryIn case of a TX error CQE, a recovery flow is triggered,mlx5e_reset_txqsq_cc_pc() resets dma_fifo_cc to 0 but not dma_fifo_pc,desyncing the DMA FIFO producer and consumer.After recovery, the producer pushes new DMA entries at the olddma_fifo_pc, while the consumer reads from position 0.This causes us to unmap stale DMA addresses from before the recovery.The DMA FIFO is a purely software construct with no HW counterpart.At the point of reset, all WQEs have been flushed so dma_fifo_cc isalready equal to dma_fifo_pc. There is no need to reset either counter,similar to how skb_fifo pc/cc are untouched.Remove the 'dma_fifo_cc = 0' reset.This fixes the following WARNING: WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommu_dma_unmap_page+0x79/0x90 Modules linked in: mlx5_vdpa vringh vdpa bonding mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter overlay zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [last unloaded: nf_tables] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommu_dma_unmap_page+0x79/0x90 Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 Call Trace: ? __warn+0x7d/0x110 ? iommu_dma_unmap_page+0x79/0x90 ? report_bug+0x16d/0x180 ? handle_bug+0x4f/0x90 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? iommu_dma_unmap_page+0x79/0x90 ? iommu_dma_unmap_page+0x2e/0x90 dma_unmap_page_attrs+0x10d/0x1b0 mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core] mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core] mlx5e_napi_poll+0x8b/0xac0 [mlx5_core] __napi_poll+0x24/0x190 net_rx_action+0x32a/0x3b0 ? mlx5_eq_comp_int+0x7e/0x270 [mlx5_core] ? notifier_call_chain+0x35/0xa0 handle_softirqs+0xc9/0x270 irq_exit_rcu+0x71/0xd0 common_interrupt+0x7f/0xa0 asm_common_interrupt+0x22/0x40
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfs: return EISDIR on nfs3_proc_create if d_alias is a dirIf we found an alias through nfs3_do_create/nfs_add_or_obtain/d_splice_alias which happens to be a dir dentry, we don't returnany error, and simply forget about this alias, but the originaldentry we were adding and passed as parameter remains negative.This later causes an oops on nfs_atomic_open_v23/finish_open since wesupply a negative dentry to do_dentry_open.This has been observed running lustre-racer, where dirs and files arecreated/removed concurrently with the same name and O_EXCL is notused to open files (frequent file redirection).While d_splice_alias typically returns a directory alias or NULL, weexplicitly check d_is_dir() to ensure that we don't attempt to performfile operations (like finish_open) on a directory inode, which triggersthe observed oops.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:unshare: fix unshare_fs() handlingThere's an unpleasant corner case in unshare(2), when we have aCLONE_NEWNS in flags and current->fs hadn't been shared at all; in thatcase copy_mnt_ns() gets passed current->fs instead of a private copy,which causes interesting warts in proof of correctness]> I guess if private means fs->users == 1, the condition could still be true.Unfortunately, it's worse than just a convoluted proof of correctness.Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS(and current->fs->users == 1).We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds andflips current->fs->{pwd,root} to corresponding locations in the new namespace.Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM).We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it'sdestroyed and its mount tree is dissolved, but... current->fs->root andcurrent->fs->pwd are both left pointing to now detached mounts.They are pinning those, so it's not a UAF, but it leaves the callingprocess with unshare(2) failing with -ENOMEM _and_ leaving it withpwd and root on detached isolated mounts. The last part is clearly a bug.There is other fun related to that mess (races with pivot_root(), includingthe one between pivot_root() and fork(), of all things), but this oneis easy to isolate and fix - treat CLONE_NEWNS as "allocate a newfs_struct even if it hadn't been shared in the first place". Sure, we couldgo for something like "if both CLONE_NEWNS *and* one of the things that mightend up failing after copy_mnt_ns() call in create_new_namespaces() are set,force allocation of new fs_struct", but let's keep it simple - the costof copy_fs_struct() is trivial.Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* getsa freshly allocated fs_struct, yet to be attached to anything. Thatseriously simplifies the analysis...FWIW, that bug had been there since the introduction of unshare(2) ;-/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: storvsc: Fix scheduling while atomic on PREEMPT_RTThis resolves the follow splat and lock-up when running with PREEMPT_RTenabled on Hyper-V:[ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002[ 415.140822] INFO: lockdep is turned off.[ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common[ 415.140846] Preemption disabled at:[ 415.140847] [] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc][ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)}[ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024[ 415.140857] Call Trace:[ 415.140861] [ 415.140861] ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc][ 415.140863] dump_stack_lvl+0x91/0xb0[ 415.140870] __schedule_bug+0x9c/0xc0[ 415.140875] __schedule+0xdf6/0x1300[ 415.140877] ? rtlock_slowlock_locked+0x56c/0x1980[ 415.140879] ? rcu_is_watching+0x12/0x60[ 415.140883] schedule_rtlock+0x21/0x40[ 415.140885] rtlock_slowlock_locked+0x502/0x1980[ 415.140891] rt_spin_lock+0x89/0x1e0[ 415.140893] hv_ringbuffer_write+0x87/0x2a0[ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0[ 415.140900] ? rcu_is_watching+0x12/0x60[ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc][ 415.140904] ? HARDIRQ_verbose+0x10/0x10[ 415.140908] ? __rq_qos_issue+0x28/0x40[ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod][ 415.140926] __blk_mq_issue_directly+0x4a/0xc0[ 415.140928] blk_mq_issue_direct+0x87/0x2b0[ 415.140931] blk_mq_dispatch_queue_requests+0x120/0x440[ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0[ 415.140935] __blk_flush_plug+0xf4/0x150[ 415.140940] __submit_bio+0x2b2/0x5c0[ 415.140944] ? submit_bio_noacct_nocheck+0x272/0x360[ 415.140946] submit_bio_noacct_nocheck+0x272/0x360[ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4][ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4][ 415.141018] ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4][ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4][ 415.141060] generic_perform_write+0x14e/0x2c0[ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4][ 415.141083] vfs_write+0x2ca/0x570[ 415.141087] ksys_write+0x76/0xf0[ 415.141089] do_syscall_64+0x99/0x1490[ 415.141093] ? rcu_is_watching+0x12/0x60[ 415.141095] ? finish_task_switch.isra.0+0xdf/0x3d0[ 415.141097] ? rcu_is_watching+0x12/0x60[ 415.141098] ? lock_release+0x1f0/0x2a0[ 415.141100] ? rcu_is_watching+0x12/0x60[ 415.141101] ? finish_task_switch.isra.0+0xe4/0x3d0[ 415.141103] ? rcu_is_watching+0x12/0x60[ 415.141104] ? __schedule+0xb34/0x1300[ 415.141106] ? hrtimer_try_to_cancel+0x1d/0x170[ 415.141109] ? do_nanosleep+0x8b/0x160[ 415.141111] ? hrtimer_nanosleep+0x89/0x100[ 415.141114] ? __pfx_hrtimer_wakeup+0x10/0x10[ 415.141116] ? xfd_validate_state+0x26/0x90[ 415.141118] ? rcu_is_watching+0x12/0x60[ 415.141120] ? do_syscall_64+0x1e0/0x1490[ 415.141121] ? do_syscall_64+0x1e0/0x1490[ 415.141123] ? rcu_is_watching+0x12/0x60[ 415.141124] ? do_syscall_64+0x1e0/0x1490[ 415.141125] ? do_syscall_64+0x1e0/0x1490[ 415.141127] ? irqentry_exit+0x140/0---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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activatedExplicitly set/clear CR8 write interception when AVIC is (de)activated tofix a bug where KVM leaves the interception enabled after AVIC isactivated. E.g. if KVM emulates INIT=>WFS while AVIC is deactivated, CR8will remain intercepted in perpetuity.On its own, the dangling CR8 intercept is "just" a performance issue, butcombined with the TPR sync bug fixed by commit d02e48830e3f ("KVM: SVM:Sync TPR from LAPIC into VMCB::V_TPR even if AVIC is active"), the dangingintercept is fatal to Windows guests as the TPR seen by hardware getswildly out of sync with reality.Note, VMX isn't affected by the bug as TPR_THRESHOLD is explicitly ignoredwhen Virtual Interrupt Delivery is enabled, i.e. when APICv is active inKVM's world. I.e. there's no need to trigger update_cr8_intercept(), thisis firmly an SVM implementation flaw/detail.WARN if KVM gets a CR8 write #VMEXIT while AVIC is active, as KVM shouldnever enter the guest with AVIC enabled and CR8 writes intercepted.[Squash fix to avic_deactivate_vmcb. - Paolo]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mmc: core: Avoid bitfield RMW for claim/retune flagsMove claimed and retune control flags out of the bitfield word toavoid unrelated RMW side effects in asynchronous contexts.The host->claimed bit shared a word with retune flags. Writes to claimedin __mmc_claim_host() or retune_now in mmc_mq_queue_rq() can overwriteother bits when concurrent updates happen in other contexts, triggeringspurious WARN_ON(!host->claimed). Convert claimed, can_retune,retune_now and retune_paused to bool to remove shared-word coupling.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: A flaw was found in polkit. A local user can exploit this by providing a specially crafted, excessively long input to the `polkit-agent-helper-1` setuid binary via standard input (stdin). This unbounded input can lead to an out-of-memory (OOM) condition, resulting in a Denial of Service (DoS) for the system.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libpolkit0 > 0-0 (version in image is 0.113-5.35.1).
-
Description: A flaw was found in tar. A remote attacker could exploit this vulnerability by crafting a malicious archive, leading to hidden file injection with fully attacker-controlled content. This bypasses pre-extraction inspection mechanisms, potentially allowing an attacker to introduce malicious files onto a system without detection.
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: A flaw was found in libefiboot, a component of efivar. The device path node parser in libefiboot fails to validate that each node's Length field is at least 4 bytes, which is the minimum size for an EFI (Extensible Firmware Interface) device path node header. A local user could exploit this vulnerability by providing a specially crafted device path node. This can lead to infinite recursion, causing stack exhaustion and a process crash, resulting in a denial of service (DoS).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libefivar1 > 0-0 (version in image is 31-3.3.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.48.4).
- 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-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- python-Jinja2 > 0-0 (version in image is 2.8-22.11.1).
-
Description: 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.51.3-9.47.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: ctxfi: Fix potential OOB access in audio mixer handlingIn the audio mixer handling code of ctxfi driver, the conf field isused as a kind of loop index, and it's referred in the index callbacks(amixer_index() and sum_index()).As spotted recently by fuzzers, the current code causes OOB access atthose functions.| UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48| index 8 is out of range for type 'unsigned char [8]'After the analysis, the cause was found to be the lack of the proper(re-)initialization of conj field.This patch addresses those OOB accesses by adding the properinitializations of the loop indices.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify()Initialize le_tmp64 to zero in rtw_BIP_verify() to prevent usinguninitialized data.Smatch warns that only 6 bytes are copied to this 8-byte (u64)variable, leaving the last two bytes uninitialized:drivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify()warn: not copying enough bytes for '&le_tmp64' (8 vs 6 bytes)Initializing the variable at the start of the function fixes thiswarning and ensures predictable behavior.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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.180.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: An uncontrolled resource consumption (memory leak) flaw was found in the ZeroMQ client in versions before 4.3.3 in src/pipe.cpp. This issue causes a client that connects to multiple malicious or compromised servers to crash. The highest threat from this vulnerability is to system availability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libzmq3 > 0-0 (version in image is 4.0.4-15.8.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-rdma: fix possible use-after-free in transport error_recovery workWhile nvme_rdma_submit_async_event_work is checking the ctrl and queuestate before preparing the AER command and scheduling io_work, in orderto fully prevent a race where this check is not reliable the errorrecovery work must flush async_event_work before continuing to destroythe admin queue after setting the ctrl state to RESETTING such thatthere is no race .submit_async_event and the error recovery handleritself changing the ctrl state.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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.302.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.302.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.302.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: REXML is an XML toolkit for Ruby. The REXML gem before 3.2.6 has a denial of service vulnerability when it parses an XML that has many `<`s in an attribute value. Those who need to parse untrusted XMLs may be impacted to this vulnerability. The REXML gem 3.2.7 or later include the patch to fix this vulnerability. As a workaround, don't parse untrusted XMLs.
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: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.302.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.302.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.39.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.39.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.120.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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.120.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.120.1).
-
Description: A flaw was found in GnuTLS. This vulnerability allows a denial of service (DoS) by excessive CPU (Central Processing Unit) and memory consumption via specially crafted malicious certificates containing a large number of name constraints and subject alternative names (SANs).
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: 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.120.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: 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.48.4).
-
Description: xz is a pure golang package for reading and writing xz-compressed files. Prior to version 0.5.14, it is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn't include a magic number or has a checksum to detect such an issue according to the specification. Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done. This issue has been patched in version 0.5.14.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- google-osconfig-agent > 0-0 (version in image is 20250416.02-1.41.1).
-
Description: SSH servers parsing GSSAPI authentication requests do not validate the number of mechanisms specified in the request, allowing an attacker to cause unbounded memory consumption.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- google-guest-agent > 0-0 (version in image is 20250506.01-1.53.1).
-
Description: urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.24 and prior to 2.6.0, the number of links in the decompression chain was unbounded allowing a malicious server to insert a virtually unlimited number of compression steps leading to high CPU usage and massive memory allocation for the decompressed data. This vulnerability is fixed in 2.6.0.
Packages affected:
- 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.48.4).
-
Description: urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.0 and prior to 2.6.0, the Streaming API improperly handles highly compressed data. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. When streaming a compressed response, urllib3 can perform decoding or decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). The library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation. The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python-urllib3 > 0-0 (version in image is 1.25.10-3.48.4).
-
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.2.0280-17.62.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.99.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf: Fix __perf_event_overflow() vs perf_remove_from_context() raceMake sure that __perf_event_overflow() runs with IRQs disabled for allpossible callchains. Specifically the software events can end up runningit with only preemption disabled.This opens up a race vs perf_event_exit_event() and friends that will goand free various things the overflow path expects to be present, likethe BPF program.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: lec: fix null-ptr-deref in lec_arp_clear_vccssyzkaller reported a null-ptr-deref in lec_arp_clear_vccs().This issue can be easily reproduced using the syzkaller reproducer.In the ATM LANE (LAN Emulation) module, the same atm_vcc can be shared bymultiple lec_arp_table entries (e.g., via entry->vcc or entry->recv_vcc).When the underlying VCC is closed, lec_vcc_close() iterates over allARP entries and calls lec_arp_clear_vccs() for each matched entry.For example, when lec_vcc_close() iterates through the hlists inpriv->lec_arp_empty_ones or other ARP tables:1. In the first iteration, for the first matched ARP entry sharing the VCC,lec_arp_clear_vccs() frees the associated vpriv (which is vcc->user_back)and sets vcc->user_back to NULL.2. In the second iteration, for the next matched ARP entry sharing the sameVCC, lec_arp_clear_vccs() is called again. It obtains a NULL vpriv fromvcc->user_back (via LEC_VCC_PRIV(vcc)) and then attempts to dereference itvia `vcc->pop = vpriv->old_pop`, leading to a null-ptr-deref crash.Fix this by adding a null check for vpriv before dereferencingit. If vpriv is already NULL, it means the VCC has been clearedby a previous call, so we can safely skip the cleanup and justclear the entry's vcc/recv_vcc pointers.The entire cleanup block (including vcc_release_async()) is placed insidethe vpriv guard because a NULL vpriv indicates the VCC has already beenfully released by a prior iteration - repeating the teardown wouldredundantly set flags and trigger callbacks on an already-closing socket.The Fixes tag points to the initial commit because the entry->vcc path hasbeen vulnerable since the original code. The entry->recv_vcc path was lateradded by commit 8d9f73c0ad2f ("atm: fix a memory leak of vcc->user_back")with the same pattern, and both paths are fixed here.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS caseIn decode_int(), the CONS case calls get_bits(bs, 2) to read a lengthvalue, then calls get_uint(bs, len) without checking that len bytesremain in the buffer. The existing boundary check only validates the2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint()reads. This allows a malformed H.323/RAS packet to cause a 1-4 byteslab-out-of-bounds read.Add a boundary check for len bytes after get_bits() and beforeget_uint().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp()sip_help_tcp() parses the SIP Content-Length header withsimple_strtoul(), which returns unsigned long, but stores the result inunsigned int clen. On 64-bit systems, values exceeding UINT_MAX aresilently truncated before computing the SIP message boundary.For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32,causing the parser to miscalculate where the current message ends. Theloop then treats trailing data in the TCP segment as a second SIPmessage and processes it through the SDP parser.Fix this by changing clen to unsigned long to match the return type ofsimple_strtoul(), and reject Content-Length values that exceed theremaining TCP payload 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del()l2cap_conn_del() calls cancel_delayed_work_sync() for both info_timerand id_addr_timer while holding conn->lock. However, the work functionsl2cap_info_timeout() and l2cap_conn_update_id_addr() both acquireconn->lock, creating a potential AB-BA deadlock if the work is alreadyexecuting when l2cap_conn_del() takes the lock.Move the work cancellations before acquiring conn->lock and usedisable_delayed_work_sync() to additionally prevent the works frombeing rearmed after cancellation, consistent with the pattern used inhci_conn_del().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: caiaq: take a reference on the USB device in create_card()The caiaq driver stores a pointer to the parent USB device incdev->chip.dev but never takes a reference on it. The card'sprivate_free callback, snd_usb_caiaq_card_free(), can runasynchronously via snd_card_free_when_closed() after the USBdevice has already been disconnected and freed, so any access tocdev->chip.dev in that path dereferences a freed usb_device.On top of the refcounting issue, the current card_free implementationcalls usb_reset_device(cdev->chip.dev). A reset in a free callbackis inappropriate: the device is going away, the call takes thedevice lock in a teardown context, and the reset races with thedisconnect path that the callback is already cleaning up after.Take a reference on the USB device in create_card() withusb_get_dev(), drop it with usb_put_dev() in the free callback,and remove the usb_reset_device() 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.302.1).
-
Description: When calling base64.b64decode() or related functions the decoding process would stop after encountering the first padded quad regardless of whether there was more information to be processed. This can lead to data being accepted which may be processed differently by other implementations. Use "validate=True" to enable stricter processing of base64 data.
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.74.1).
-
Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.16 and prior, there is a heap-based buffer overflow in the CUPS scheduler when building filter option strings from job attribute. At time of publication, there are no publicly available patches.
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.62.1).
-
Description: A weakness has been identified in libssh up to 0.11.3. The impacted element is the function sftp_extensions_get_name/sftp_extensions_get_data of the file src/sftp.c of the component SFTP Extension Name Handler. Executing a manipulation of the argument idx can lead to out-of-bounds read. The attack may be performed from remote. Upgrading to version 0.11.4 and 0.12.0 is sufficient to resolve this issue. This patch is called 855a0853ad3abd4a6cd85ce06fce6d8d4c7a0b60. You should upgrade the affected component.
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.21.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md-cluster: fix NULL pointer dereference in process_metadata_updateThe function process_metadata_update() blindly dereferences the 'thread'pointer (acquired via rcu_dereference_protected) within the wait_event()macro.While the code comment states "daemon thread must exist", there is a validrace condition window during the MD array startup sequence (md_run):1. bitmap_load() is called, which invokes md_cluster_ops->join().2. join() starts the "cluster_recv" thread (recv_daemon).3. At this point, recv_daemon is active and processing messages.4. However, mddev->thread (the main MD thread) is not initialized until later in md_run().If a METADATA_UPDATED message is received from a remote node during thisspecific window, process_metadata_update() will be called whilemddev->thread is still NULL, leading to a kernel panic.To fix this, we must validate the 'thread' pointer. If it is NULL, werelease the held lock (no_new_dev_lockres) and return early, safelyignoring the update request as the array is not yet fully ready toprocess 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.302.1).
-
Description: The deprecated functions ns_printrrf, ns_printrr and fp_nquery in the GNU C Library version 2.2 and newer fail to enforce the caller-supplied buffer length, and can result in an out-of-bounds write when printing TSIG records.
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.43.1).
-
Description: The deprecated functions ns_printrrf, ns_printrr and fp_nquery in the GNU C Library version 2.2 and newer fail to validate the RDATA content against the RDATA length in a DNS response when processing LOC, CERT, TKEY or TSIG records, which may allow an attacker to craft a DNS response, causing a target application to crash or read uninitialized memory.These functions are for application debugging only and hence not in the path of code executed by the DNS resolver. Further, they have been deprecated since version 2.34 and should not be used by any new applications. Applications should consider porting away from these interfaces since they may be removed in future versions.
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.43.1).
-
Description: The ftpcp() function in Lib/ftplib.py was not updated when CVE-2021-4189 was fixed. While makepasv() was patched to replace server-supplied PASV host addresses with the actual peer address (getpeername()[0]), ftpcp() still calls parse227() directly and passes the raw attacker-controllable IP address and port to target.sendport(). This patch is related to CVE-2021-4189.
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.74.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.302.1).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.0.9 to before 1.6.57, passing a pointer obtained from png_get_PLTE, png_get_tRNS, or png_get_hIST back into the corresponding setter on the same png_struct/png_info pair causes the setter to read from freed memory and copy its contents into the replacement buffer. The setter frees the internal buffer before copying from the caller-supplied pointer, which now dangles. The freed region may contain stale data (producing silently corrupted chunk metadata) or data from subsequent heap allocations (leaking unrelated heap contents into the chunk struct). This vulnerability is fixed in 1.6.57.
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.24.1).
-
Description: A malicious SCP server can send unexpected paths that could make theclient application override local files outside of working directory.This could be misused to create malicious executable or configurationfiles and make the user execute them under specific consequences.This is the same issue as in OpenSSH, tracked as CVE-2019-6111.
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.21.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.302.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-196.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-196.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-196.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-196.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.58.1).
-
Description: CR/LF bytes were not rejected by HTTP client proxy tunnel headers or host.
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.74.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.74.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.58.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-196.1).
-
Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.16 and prior, CUPS daemon (cupsd) contains an authorization bypass vulnerability due to case-insensitive username comparison during authorization checks. The vulnerability allows an unprivileged user to gain unauthorized access to restricted operations by using a user with a username that differs only in case from an authorized user. At time of publication, there are no publicly available patches.
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.62.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: avoid OGM aggregation when skb tailroom is insufficientWhen OGM aggregation state is toggled at runtime, an existing forwardedpacket may have been allocated with only packet_len bytes, while a laterpacket can still be selected for aggregation. Appending in this case canhit skb_put overflow conditions.Reject aggregation when the target skb tailroom cannot accommodate the newpacket. The caller then falls back to creating a new forward packetinstead of appending.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: A flaw was found in gnutls. This vulnerability occurs because permitted name constraints were incorrectly ignored when previous Certificate Authorities (CAs) only had excluded name constraints. A remote attacker could exploit this to bypass critical name constraint checks during certificate validation. This bypass could lead to the acceptance of invalid certificates, potentially enabling spoofing or man-in-the-middle attacks against affected systems.
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: Unknown.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- vim > 0-0 (version in image is 9.2.0280-17.62.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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-196.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.302.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.302.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.302.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.302.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.75.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't log conflicting inode if it's a dir moved in the current transactionWe can't log a conflicting inode if it's a directory and it was movedfrom one parent directory to another parent directory in the currenttransaction, as this can result an attempt to have a directory withtwo hard links during log replay, one for the old parent directory andanother for the new parent directory.The following scenario triggers that issue:1) We have directories "dir1" and "dir2" created in a past transaction. Directory "dir1" has inode A as its parent directory;2) We move "dir1" to some other directory;3) We create a file with the name "dir1" in directory inode A;4) We fsync the new file. This results in logging the inode of the new file and the inode for the directory "dir1" that was previously moved in the current transaction. So the log tree has the INODE_REF item for the new location of "dir1";5) We move the new file to some other directory. This results in updating the log tree to included the new INODE_REF for the new location of the file and removes the INODE_REF for the old location. This happens during the rename when we call btrfs_log_new_name();6) We fsync the file, and that persists the log tree changes done in the previous step (btrfs_log_new_name() only updates the log tree in memory);7) We have a power failure;8) Next time the fs is mounted, log replay happens and when processing the inode for directory "dir1" we find a new INODE_REF and add that link, but we don't remove the old link of the inode since we have not logged the old parent directory of the directory inode "dir1".As a result after log replay finishes when we trigger writeback of thesubvolume tree's extent buffers, the tree check will detect that we havea directory a hard link count of 2 and we get a mount failure.The errors and stack traces reported in dmesg/syslog are like this: [ 3845.729764] BTRFS info (device dm-0): start tree-log replay [ 3845.730304] page: refcount:3 mapcount:0 mapping:000000005c8a3027 index:0x1d00 pfn:0x11510c [ 3845.731236] memcg:ffff9264c02f4e00 [ 3845.731751] aops:btree_aops [btrfs] ino:1 [ 3845.732300] flags: 0x17fffc00000400a(uptodate|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [ 3845.733346] raw: 017fffc00000400a 0000000000000000 dead000000000122 ffff9264d978aea8 [ 3845.734265] raw: 0000000000001d00 ffff92650e6d4738 00000003ffffffff ffff9264c02f4e00 [ 3845.735305] page dumped because: eb page dump [ 3845.735981] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=6 ino=257, invalid nlink: has 2 expect no more than 1 for dir [ 3845.737786] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14881 owner 5 [ 3845.737789] BTRFS info (device dm-0): refs 4 lock_owner 0 current 30701 [ 3845.737792] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [ 3845.737794] inode generation 3 transid 9 size 16 nbytes 16384 [ 3845.737795] block group 0 mode 40755 links 1 uid 0 gid 0 [ 3845.737797] rdev 0 sequence 2 flags 0x0 [ 3845.737798] atime 1764259517.0 [ 3845.737800] ctime 1764259517.572889464 [ 3845.737801] mtime 1764259517.572889464 [ 3845.737802] otime 1764259517.0 [ 3845.737803] item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12 [ 3845.737805] index 0 name_len 2 [ 3845.737807] item 2 key (256 DIR_ITEM 2363071922) itemoff 16077 itemsize 34 [ 3845.737808] location key (257 1 0) type 2 [ 3845.737810] transid 9 data_len 0 name_len 4 [ 3845.737811] item 3 key (256 DIR_ITEM 2676584006) itemoff 16043 itemsize 34 [ 3845.737813] location key (258 1 0) type 2 [ 3845.737814] transid 9 data_len 0 name_len 4 [ 3845.737815] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [ 3845.737816] location key (257 1 0) type 2 [---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.302.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.21.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pNFS: Fix a deadlock when returning a delegation during open()Ben Coddington reports seeing a hang in the following stack trace: 0 [ffffd0b50e1774e0] __schedule at ffffffff9ca05415 1 [ffffd0b50e177548] schedule at ffffffff9ca05717 2 [ffffd0b50e177558] bit_wait at ffffffff9ca061e1 3 [ffffd0b50e177568] __wait_on_bit at ffffffff9ca05cfb 4 [ffffd0b50e1775c8] out_of_line_wait_on_bit at ffffffff9ca05ea5 5 [ffffd0b50e177618] pnfs_roc at ffffffffc154207b [nfsv4] 6 [ffffd0b50e1776b8] _nfs4_proc_delegreturn at ffffffffc1506586 [nfsv4] 7 [ffffd0b50e177788] nfs4_proc_delegreturn at ffffffffc1507480 [nfsv4] 8 [ffffd0b50e1777f8] nfs_do_return_delegation at ffffffffc1523e41 [nfsv4] 9 [ffffd0b50e177838] nfs_inode_set_delegation at ffffffffc1524a75 [nfsv4] 10 [ffffd0b50e177888] nfs4_process_delegation at ffffffffc14f41dd [nfsv4] 11 [ffffd0b50e1778a0] _nfs4_opendata_to_nfs4_state at ffffffffc1503edf [nfsv4] 12 [ffffd0b50e1778c0] _nfs4_open_and_get_state at ffffffffc1504e56 [nfsv4] 13 [ffffd0b50e177978] _nfs4_do_open at ffffffffc15051b8 [nfsv4] 14 [ffffd0b50e1779f8] nfs4_do_open at ffffffffc150559c [nfsv4] 15 [ffffd0b50e177a80] nfs4_atomic_open at ffffffffc15057fb [nfsv4] 16 [ffffd0b50e177ad0] nfs4_file_open at ffffffffc15219be [nfsv4] 17 [ffffd0b50e177b78] do_dentry_open at ffffffff9c09e6ea 18 [ffffd0b50e177ba8] vfs_open at ffffffff9c0a082e 19 [ffffd0b50e177bd0] dentry_open at ffffffff9c0a0935The issue is that the delegreturn is being asked to wait for a layoutreturn that cannot complete because a state recovery was initiated. Thestate recovery cannot complete until the open() finishes processing thedelegations it was given.The solution is to propagate the existing flags that indicate anon-blocking call to the function pnfs_roc(), so that it knows not towait in this situation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leakFix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:gs_usb_receive_bulk_callback(): fix URB memory leak").In kvaser_usb_set_{,data_}bittiming() -> kvaser_usb_setup_rx_urbs(), theURBs for USB-in transfers are allocated, added to the dev->rx_submittedanchor and submitted. In the complete callbackkvaser_usb_read_bulk_callback(), the URBs are processed and resubmitted. Inkvaser_usb_remove_interfaces() the URBs are freed by callingusb_kill_anchored_urbs(&dev->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 usb_kill_anchored_urbs().Fix the memory leak by anchoring the URB in thekvaser_usb_read_bulk_callback() to the dev->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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: add proper RCU protection to /proc/net/ptypeYin Fengwei reported an RCU stall in ptype_seq_show() and provideda patch.Real issue is that ptype_seq_next() and ptype_seq_show() violateRCU rules.ptype_seq_show() runs under rcu_read_lock(), and reads pt->devto get device name without any barrier.At the same time, concurrent writers can remove a packet_type structure(which is correctly freed after an RCU grace period) and clear pt->devwithout an RCU grace period.Define ptype_iter_state to carry a dev pointer along seq_net_private:struct ptype_iter_state { struct seq_net_private p; struct net_device *dev; // added in this patch};We need to record the device pointer in ptype_get_idx() andptype_seq_next() so that ptype_seq_show() is safe againstconcurrent pt->dev changes.We also need to add full RCU protection in ptype_seq_next().(Missing READ_ONCE() when reading list.next values)Many thanks to Dong Chenchen for providing a repro.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: Avoid boot crash in RedBoot partition table parserGiven CONFIG_FORTIFY_SOURCE=y and a recent compiler,commit 439a1bcac648 ("fortify: Use __builtin_dynamic_object_size() whenavailable") produces the warning below and an oops. Searching for RedBoot partition table in 50000000.flash at offset 0x7e0000 ------------[ cut here ]------------ WARNING: lib/string_helpers.c:1035 at 0xc029e04c, CPU#0: swapper/0/1 memcmp: detected buffer overflow: 15 byte read of buffer size 14 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0 #1 NONEAs Kees said, "'names' is pointing to the final 'namelen' many bytesof the allocation ... 'namelen' could be basically any length at all.This fortify warning looks legit to me -- this code used to be readingbeyond the end of the allocation."Since the size of the dynamic allocation is calculated with strlen()we can use strcmp() instead of memcmp() and remain within 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.302.1).
-
Description: util-linux is a random collection of Linux utilities. Prior to version 2.41.4, a TOCTOU (Time-of-Check-Time-of-Use) vulnerability has been identified in the SUID binary /usr/bin/mount from util-linux. The mount binary, when setting up loop devices, validates the source file path with user privileges via fork() + setuid() + realpath(), but subsequently re-canonicalizes and opens it with root privileges (euid=0) without verifying that the path has not been replaced between both operations. Neither O_NOFOLLOW, nor inode comparison, nor post-open fstat() are employed. This allows a local unprivileged user to replace the source file with a symlink pointing to any root-owned file or device during the race window, causing the SUID binary to open and mount it as root. Exploitation requires an /etc/fstab entry with user,loop options whose path points to a directory where the attacker has write permission, and that /usr/bin/mount has the SUID bit set (the default configuration on virtually all Linux distributions). The impact is unauthorized read access to root-protected files and block devices, including backup images, disk volumes, and any file containing a valid filesystem. This issue has been patched in version 2.41.4.
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.51.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvdimm/bus: Fix potential use after free in asynchronous initializationDingisoul with KASAN reports a use after free if device_add() fails innd_async_device_register().Commit b6eae0f61db2 ("libnvdimm: Hold reference on parent whilescheduling async init") correctly added a reference on the parent deviceto be held until asynchronous initialization was complete. However, ifdevice_add() results in an allocation failure the ref count of thedevice drops to 0 prior to the parent pointer being accessed. Thusresulting in use after free.The bug bot AI correctly identified the fix. Save a reference to theparent pointer to be used to drop the parent reference regardless of theoutcome of device_add().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: fix reference count leak in rxrpc_server_keyring()This patch fixes a reference count leak in rxrpc_server_keyring()by checking if rx->securities is already 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit()When dma_map_single() fails in tse_start_xmit(), the function returnsNETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells thestack the packet was consumed, the skb is never freed, leaking memoryon every DMA mapping failure.Add dev_kfree_skb_any() before returning to properly free the 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: uinput - fix circular locking dependency with ff-coreA lockdep circular locking dependency warning can be triggeredreproducibly when using a force-feedback gamepad with uinput (forexample, playing ELDEN RING under Wine with a Flydigi Vader 5controller): ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutexThe cycle is caused by four lock acquisition paths:1. ff upload: input_ff_upload() holds ff->mutex and calls uinput_dev_upload_effect() -> uinput_request_submit() -> uinput_request_send(), which acquires udev->mutex.2. device create: uinput_ioctl_handler() holds udev->mutex and calls uinput_create_device() -> input_register_device(), which acquires input_mutex.3. device register: input_register_device() holds input_mutex and calls kbd_connect() -> input_register_handle(), which acquires dev->mutex.4. evdev release: evdev_release() calls input_flush_device() under dev->mutex, which calls input_ff_flush() acquiring ff->mutex.Fix this by introducing a new state_lock spinlock to protectudev->state and udev->dev access in uinput_request_send() instead ofacquiring udev->mutex. The function only needs to atomically checkdevice state and queue an input event into the ring buffer viauinput_dev_event() -- both operations are safe under a spinlock(ktime_get_ts64() and wake_up_interruptible() do not sleep). Thisbreaks the ff->mutex -> udev->mutex link since a spinlock is a leaf inthe lock ordering and cannot form cycles with mutexes.To keep state transitions visible to uinput_request_send(), protectwrites to udev->state in uinput_create_device() anduinput_destroy_device() with the same state_lock spinlock.Additionally, move init_completion(&request->done) fromuinput_request_send() to uinput_request_submit() beforeuinput_request_reserve_slot(). Once the slot is allocated,uinput_flush_requests() may call complete() on it at any time fromthe destroy path, so the completion must be initialised before therequest becomes visible.Lock ordering after the fix: ff->mutex -> state_lock (spinlock, leaf) udev->mutex -> state_lock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: flowlabel: defer exclusive option free until RCU teardown`ip6fl_seq_show()` walks the global flowlabel hash under the seq-fileRCU read-side lock and prints `fl->opt->opt_nflen` when an option blockis present.Exclusive flowlabels currently free `fl->opt` as soon as `fl->users`drops to zero in `fl_release()`. However, the surrounding`struct ip6_flowlabel` remains visible in the global hash table untillater garbage collection removes it and `fl_free_rcu()` finally tears itdown.A concurrent `/proc/net/ip6_flowlabel` reader can therefore race thatearly `kfree()` and dereference freed option state, triggering a crashin `ip6fl_seq_show()`.Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matchesthe lifetime already required for the enclosing flowlabel while readerscan still reach it under 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: u_ether: Fix race between gether_disconnect and eth_stopA race condition between gether_disconnect() and eth_stop() leads to aNULL pointer dereference. Specifically, if eth_stop() is triggeredconcurrently while gether_disconnect() is tearing down the endpoints,eth_stop() attempts to access the cleared endpoint descriptor, causingthe following NPE: Unable to handle kernel NULL pointer dereference Call trace: __dwc3_gadget_ep_enable+0x60/0x788 dwc3_gadget_ep_enable+0x70/0xe4 usb_ep_enable+0x60/0x15c eth_stop+0xb8/0x108Because eth_stop() crashes while holding the dev->lock, the threadrunning gether_disconnect() fails to acquire the same lock and spinsforever, resulting in a hardlockup: Core - Debugging Information for Hardlockup core(7) Call trace: queued_spin_lock_slowpath+0x94/0x488 _raw_spin_lock+0x64/0x6c gether_disconnect+0x19c/0x1e8 ncm_set_alt+0x68/0x1a0 composite_setup+0x6a0/0xc50The root cause is that the clearing of dev->port_usb ingether_disconnect() is delayed until the end of the function.Move the clearing of dev->port_usb to the very beginning ofgether_disconnect() while holding dev->lock. This cuts off the linkimmediately, ensuring eth_stop() will see dev->port_usb as NULL andsafely bail 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: libertas: fix WARNING in usb_tx_blockThe function usb_tx_block() submits cardp->tx_urb without ensuring thatany previous transmission on this URB has completed. If a second calloccurs while the URB is still active (e.g. during rapid firmware loading),usb_submit_urb() detects the active state and triggers a warning:'URB submitted while active'.Fix this by enforcing serialization: call usb_kill_urb() beforesubmitting the new request. This ensures the URB is idle and safe to reuse.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:lib/crypto: chacha: Zeroize permuted_state before it leaves scopeSince the ChaCha permutation is invertible, the local variable'permuted_state' is sufficient to compute the original 'state', and thusthe key, even after the permutation has been done.While the kernel is quite inconsistent about zeroizing secrets on thestack (and some prominent userspace crypto libraries don't bother at allsince it's not guaranteed to work anyway), the kernel does try to do itas a best practice, especially in cases involving the RNG.Thus, explicitly zeroize 'permuted_state' before it goes out of scope.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: pegasus: validate USB endpointsThe pegasus driver should validate that the device it is probing has theproper number and types of USB endpoints it is expecting before it bindsto it. If a malicious device were to not have the same urbs the driverwill crash later on when it blindly accesses these endpoints.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: kaweth: validate USB endpointsThe kaweth driver should validate that the device it is probing has theproper number and types of USB endpoints it is expecting before it bindsto it. If a malicious device were to not have the same urbs the driverwill crash later on when it blindly accesses these endpoints.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()A malicious USB device claiming to be a CDC Phonet modem can overflowthe skb_shared_info->frags[] array by sending an unbounded sequence offull-page bulk transfers.Drop the skb and increment the length error when the frag limit isreached. This matches the same fix that commit f0813bcd2d9d ("net:wwan: t7xx: fix potential skb->frags overflow in RX path") did for thet7xx 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: magicmouse: Do not crash on missing msc->inputFake USB devices can send their own report descriptors for which theinput_mapping() hook does not get called. In this case, msc->input stays NULL,leading to a crash at a later time.Detect this condition in the input_configured() hook and reject the device.This is not supposed to happen with actual magic mouse devices, but can beprovoked by imposing as a magic mouse USB 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.302.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.302.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.2.0280-17.62.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.2.0280-17.62.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 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: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdpprocess_sdp() declares union nf_inet_addr rtp_addr on the stack andpasses it to the nf_nat_sip sdp_session hook after walking the SDPmedia descriptions. However rtp_addr is only initialized inside themedia loop when a recognized media type with a non-zero port is found.If the SDP body contains no m= lines, only inactive media sections(m=audio 0 ...) or only unrecognized media types, rtp_addr is neverassigned. Despite that, the function still calls hooks->sdp_session()with &rtp_addr, causing nf_nat_sdp_session() to format the stale stackvalue as an IP address and rewrite the SDP session owner and connectionlines with it.With CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) thisresults in the session-level o= and c= addresses being rewritten to0.0.0.0 for inactive SDP sessions. Without stack auto-init therewritten address is whatever happened to be on the stack.Fix this by pre-initializing rtp_addr from the session-level connectionaddress (caddr) when available, and tracking via a have_rtp_addr flagwhether any valid address was established. Skip the sdp_session hookentirely when no valid address exists.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: read UNIX_DIAG_VFS data under unix_state_lockExact UNIX diag lookups hold a reference to the socket, but not tou->path. Meanwhile, unix_release_sock() clears u->path underunix_state_lock() and drops the path reference after unlocking.Read the inode and device numbers for UNIX_DIAG_VFS while holdingunix_state_lock(), then emit the netlink attribute after dropping thelock.This keeps the VFS data stable while the reply is being built.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf: Fix list corruption in perf_cgroup_switch()There's list corruption on cgrp_cpuctx_list. This happens on thefollowing path: perf_cgroup_switch: list_for_each_entry(cgrp_cpuctx_list) cpu_ctx_sched_in ctx_sched_in ctx_pinned_sched_in merge_sched_in perf_cgroup_event_disable: remove the event from the listUse list_for_each_entry_safe() to allow removing an entry duringiteration.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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.302.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.302.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.302.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.302.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.302.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.302.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.2.0280-17.62.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.302.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.302.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.302.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.302.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.302.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.302.1).
-
Description: The infocmp command-line tool in ncurses before 6.5-20251213 has a stack-based buffer overflow in analyze_string in progs/infocmp.c.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libncurses5 > 0-0 (version in image is 5.9-91.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leakFix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:gs_usb_receive_bulk_callback(): fix URB memory leak").In usb_8dev_open() -> usb_8dev_start(), the URBs for USB-in transfers areallocated, added to the priv->rx_submitted anchor and submitted. In thecomplete callback usb_8dev_read_bulk_callback(), the URBs are processed andresubmitted. In usb_8dev_close() -> unlink_all_urbs() the URBs are freed bycalling usb_kill_anchored_urbs(&priv->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 usb_kill_anchored_urbs().Fix the memory leak by anchoring the URB in theusb_8dev_read_bulk_callback() to the priv->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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/imx/tve: fix probe device leakMake sure to drop the reference taken to the DDC device during probe onprobe failure (e.g. probe deferral) and on driver unbind.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Fix recursive locking in __configfs_open_file()In flush_write_buffer, &p->frag_sem is acquired and then the loaded storefunction is called, which, here, is target_core_item_dbroot_store(). Thisfunction called filp_open(), following which these functions were called(in reverse order), according to the call trace: down_read __configfs_open_file do_dentry_open vfs_open do_open path_openat do_filp_open file_open_name filp_open target_core_item_dbroot_store flush_write_buffer configfs_write_itertarget_core_item_dbroot_store() tries to validate the new file path bytrying to open the file path provided to it; however, in this case, the bugreport shows:db_root: not a directory: /sys/kernel/config/target/dbrootindicating that the same configfs file was tried to be opened, on which itis currently working on. Thus, it is trying to acquire frag_sem semaphoreof the same file of which it already holds the semaphore obtained inflush_write_buffer(), leading to acquiring the semaphore in a nested mannerand a possibility of recursive locking.Fix this by modifying target_core_item_dbroot_store() to use kern_path()instead of filp_open() to avoid opening the file using filesystem-specificfunction __configfs_open_file(), and further modifying it to make this fixcompatible.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfnetlink_osf: validate individual option lengths in fingerprintsnfnl_osf_add_callback() validates opt_num bounds and stringNUL-termination but does not check individual option length fields.A zero-length option causes nf_osf_match_one() to enter the optionmatching loop even when foptsize sums to zero, which matches packetswith no TCP options where ctx->optp is NULL: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:227) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:293) nf_hook_slow (net/netfilter/core.c:623) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573)Additionally, an MSS option (kind=2) with length < 4 causesout-of-bounds reads when nf_osf_match_one() unconditionally accessesoptp[2] and optp[3] for MSS value extraction. While RFC 9293section 3.2 specifies that the MSS option is always exactly 4bytes (Kind=2, Length=4), the check uses "< 4" rather than"!= 4" because lengths greater than 4 do not cause memorysafety issues -- the buffer is guaranteed to be at leastfoptsize bytes by the ctx->optsize == foptsize check.Reject fingerprints where any option has zero length, or where an MSSoption has length less than 4, at add time rather than trusting thesevalues in the packet matching hot 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: add missing netlink policy validationsHyunwoo Kim reports out-of-bounds access in sctp and ctnetlink.These attributes are used by the kernel without any validation.Extend the netlink policies accordingly.Quoting the reporter: nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..] and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: avoid overflows in ip6_datagram_send_ctl()Yiming Qian reported : I believe I found a locally triggerable kernel bug in the IPv6 sendmsg ancillary-data path that can panic the kernel via `skb_under_panic()` (local DoS). The core issue is a mismatch between: - a 16-bit length accumulator (`struct ipv6_txoptions::opt_flen`, type `__u16`) and - a pointer to the *last* provided destination-options header (`opt->dst1opt`) when multiple `IPV6_DSTOPTS` control messages (cmsgs) are provided. - `include/net/ipv6.h`: - `struct ipv6_txoptions::opt_flen` is `__u16` (wrap possible). (lines 291-307, especially 298) - `net/ipv6/datagram.c:ip6_datagram_send_ctl()`: - Accepts repeated `IPV6_DSTOPTS` and accumulates into `opt_flen` without rejecting duplicates. (lines 909-933) - `net/ipv6/ip6_output.c:__ip6_append_data()`: - Uses `opt->opt_flen + opt->opt_nflen` to compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465) - `net/ipv6/ip6_output.c:__ip6_make_skb()`: - Calls `ipv6_push_frag_opts()` if `opt->opt_flen` is non-zero. (lines 1930-1934) - `net/ipv6/exthdrs.c:ipv6_push_frag_opts()` / `ipv6_push_exthdr()`: - Push size comes from `ipv6_optlen(opt->dst1opt)` (based on the pointed-to header). (lines 1179-1185 and 1206-1211) 1. `opt_flen` is a 16-bit accumulator: - `include/net/ipv6.h:298` defines `__u16 opt_flen; /* after fragment hdr */`. 2. `ip6_datagram_send_ctl()` accepts *repeated* `IPV6_DSTOPTS` cmsgs and increments `opt_flen` each time: - In `net/ipv6/datagram.c:909-933`, for `IPV6_DSTOPTS`: - It computes `len = ((hdr->hdrlen + 1) << 3);` - It checks `CAP_NET_RAW` using `ns_capable(net->user_ns, CAP_NET_RAW)`. (line 922) - Then it does: - `opt->opt_flen += len;` (line 927) - `opt->dst1opt = hdr;` (line 928) There is no duplicate rejection here (unlike the legacy `IPV6_2292DSTOPTS` path which rejects duplicates at `net/ipv6/datagram.c:901-904`). If enough large `IPV6_DSTOPTS` cmsgs are provided, `opt_flen` wraps while `dst1opt` still points to a large (2048-byte) destination-options header. In the attached PoC (`poc.c`): - 32 cmsgs with `hdrlen=255` => `len = (255+1)*8 = 2048` - 1 cmsg with `hdrlen=0` => `len = 8` - Total increment: `32*2048 + 8 = 65544`, so `(__u16)opt_flen == 8` - The last cmsg is 2048 bytes, so `dst1opt` points to a 2048-byte header. 3. The transmit path sizes headers using the wrapped `opt_flen`:- In `net/ipv6/ip6_output.c:1463-1465`: - `headersize = sizeof(struct ipv6hdr) + (opt ? opt->opt_flen + opt->opt_nflen : 0) + ...;` With wrapped `opt_flen`, `headersize`/headroom decisions underestimate what will be pushed later. 4. When building the final skb, the actual push length comes from `dst1opt` and is not limited by wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1930-1934`: - `if (opt->opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);` - In `net/ipv6/exthdrs.c:1206-1211`, `ipv6_push_frag_opts()` pushes `dst1opt` via `ipv6_push_exthdr()`. - In `net/ipv6/exthdrs.c:1179-1184`, `ipv6_push_exthdr()` does: - `skb_push(skb, ipv6_optlen(opt));` - `memcpy(h, opt, ipv6_optlen(opt));` With insufficient headroom, `skb_push()` underflows and triggers `skb_under_panic()` -> `BUG()`: - `net/core/skbuff.c:2669-2675` (`skb_push()` calls `skb_under_panic()`) - `net/core/skbuff.c:207-214` (`skb_panic()` ends in `BUG()`) - The `IPV6_DSTOPTS` cmsg path requires `CAP_NET_RAW` in the target netns user namespace (`ns_capable(net->user_ns, CAP_NET_RAW)`). - Root (or any task with `CAP_NET_RAW`) can trigger this without user namespaces. - An unprivileged `uid=1000` user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespaced `CAP_NET_RAW` (the attached PoC does this). - Local denial of service: kernel BUG/panic (system crash). ----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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done()A malicious or compromised VIO server can return a num_written value in thediscover targets MAD response that exceeds max_targets. This value isstored directly in vhost->num_targets without validation, and is then usedas the loop bound in ibmvfc_alloc_targets() to index into disc_buf[], whichis only allocated for max_targets entries. Indices at or beyond max_targetsaccess kernel memory outside the DMA-coherent allocation. Theout-of-bounds data is subsequently embedded in Implicit Logout and PLOGIMADs that are sent back to the VIO server, leaking kernel memory.Fix by clamping num_written to max_targets before storing 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_key: validate families in pfkey_send_migrate()syzbot was able to trigger a crash in skb_put() [1]Issue is that pfkey_send_migrate() does not check old/new families,and that set_ipsecrequest() @family argument was truncated,thus possibly overfilling the skb.Validate families early, do not wait set_ipsecrequest().[1]skbuff: skb_over_panic: text:ffffffff8a752120 len:392 put:16 head:ffff88802a4ad040 data:ffff88802a4ad040 tail:0x188 end:0x180 dev: kernel BUG at net/core/skbuff.c:214 !Call Trace: skb_over_panic net/core/skbuff.c:219 [inline] skb_put+0x159/0x210 net/core/skbuff.c:2655 skb_put_zero include/linux/skbuff.h:2788 [inline] set_ipsecrequest net/key/af_key.c:3532 [inline] pfkey_send_migrate+0x1270/0x2e50 net/key/af_key.c:3636 km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2848 xfrm_migrate+0x2140/0x2450 net/xfrm/xfrm_policy.c:4705 xfrm_do_migrate+0x8ff/0xaa0 net/xfrm/xfrm_user.c:3150
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:module: Fix kernel panic when a symbol st_shndx is out of boundsThe module loader doesn't check for bounds of the ELF section index insimplify_symbols(): for (i = 1; i < symsec->sh_size / sizeof(Elf_Sym); i++) { const char *name = info->strtab + sym[i].st_name; switch (sym[i].st_shndx) { case SHN_COMMON: [...] default: /* Divert to percpu allocation if a percpu var. */ if (sym[i].st_shndx == info->index.pcpu) secbase = (unsigned long)mod_percpu(mod); else /** HERE --> **/ secbase = info->sechdrs[sym[i].st_shndx].sh_addr; sym[i].st_value += secbase; break; } }A symbol with an out-of-bounds st_shndx value, for example 0xffff(known as SHN_XINDEX or SHN_HIRESERVE), may cause a kernel panic: BUG: unable to handle page fault for address: ... RIP: 0010:simplify_symbols+0x2b2/0x480 ... Kernel panic - not syncing: Fatal exceptionThis can happen when module ELF is legitimately using SHN_XINDEX orwhen it is corrupted.Add a bounds check in simplify_symbols() to validate that st_shndx iswithin the valid range before using it.This issue was discovered due to a bug in llvm-objcopy, see relevantdiscussion for details [1].[1] https://lore.kernel.org/linux-modules/20251224005752.201911-1-ihor.solodrai@linux.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:seg6: separate dst_cache for input and output paths in seg6 lwtunnelThe seg6 lwtunnel uses a single dst_cache per encap route, sharedbetween seg6_input_core() and seg6_output_core(). These two pathscan perform the post-encap SID lookup in different routing contexts(e.g., ip rules matching on the ingress interface, or VRF tableseparation). Whichever path runs first populates the cache, and theother reuses it blindly, bypassing its own lookup.Fix this by splitting the cache into cache_input and cache_output,so each path maintains its own cached dst independently.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_multiport: validate range encoding in checkentryports_match_v1() treats any non-zero pflags entry as the start of aport range and unconditionally consumes the next ports[] element asthe range end.The checkentry path currently validates protocol, flags and count, butit does not validate the range encoding itself. As a result, malformedrules can mark the last slot as a range start or place two range startsback to back, leaving ports_match_v1() to step past the last validports[] element while interpreting the rule.Reject malformed multiport v1 rules in checkentry by validating thateach range start has a following element and that the following elementis not itself marked as another range start.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: reserve enough transaction items for qgroup ioctlsCurrently our qgroup ioctls don't reserve any space, they just do atransaction join, which does not reserve any space, neither for the quotatree updates nor for the delayed refs generated when updating the quotatree. The quota root uses the global block reserve, which is fine most ofthe time since we don't expect a lot of updates to the quota root, or tobe too close to -ENOSPC such that other critical metadata updates need toresort to the global reserve.However this is not optimal, as not reserving proper space may result in atransaction abort due to not reserving space for delayed refs and thenabusing the use of the global block reserve.For example, the following reproducer (which is unlikely to model anyreal world use case, but just to illustrate the problem), triggers such atransaction abort due to -ENOSPC when running delayed refs: $ cat test.sh #!/bin/bash DEV=/dev/nullb0 MNT=/mnt/nullb0 umount $DEV &> /dev/null # Limit device to 1G so that it's much faster to reproduce the issue. mkfs.btrfs -f -b 1G $DEV mount -o commit=600 $DEV $MNT fallocate -l 800M $MNT/filler btrfs quota enable $MNT for ((i = 1; i <= 400000; i++)); do btrfs qgroup create 1/$i $MNT done umount $MNTWhen running this, we can see in dmesg/syslog that a transaction aborthappened: [436.490] BTRFS error (device nullb0): failed to run delayed ref for logical 30408704 num_bytes 16384 type 176 action 1 ref_mod 1: -28 [436.493] ------------[ cut here ]------------ [436.494] BTRFS: Transaction aborted (error -28) [436.495] WARNING: fs/btrfs/extent-tree.c:2247 at btrfs_run_delayed_refs+0xd9/0x110 [btrfs], CPU#4: umount/2495372 [436.497] Modules linked in: btrfs loop (...) [436.508] CPU: 4 UID: 0 PID: 2495372 Comm: umount Tainted: G W 6.19.0-rc8-btrfs-next-225+ #1 PREEMPT(full) [436.510] Tainted: [W]=WARN [436.511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [436.513] RIP: 0010:btrfs_run_delayed_refs+0xdf/0x110 [btrfs] [436.514] Code: 0f 82 ea (...) [436.518] RSP: 0018:ffffd511850b7d78 EFLAGS: 00010292 [436.519] RAX: 00000000ffffffe4 RBX: ffff8f120dad37e0 RCX: 0000000002040001 [436.520] RDX: 0000000000000002 RSI: 00000000ffffffe4 RDI: ffffffffc090fd80 [436.522] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffc04d1867 [436.523] R10: ffff8f18dc1fffa8 R11: 0000000000000003 R12: ffff8f173aa89400 [436.524] R13: 0000000000000000 R14: ffff8f173aa89400 R15: 0000000000000000 [436.526] FS: 00007fe59045d840(0000) GS:ffff8f192e22e000(0000) knlGS:0000000000000000 [436.527] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [436.528] CR2: 00007fe5905ff2b0 CR3: 000000060710a002 CR4: 0000000000370ef0 [436.530] Call Trace: [436.530] [436.530] btrfs_commit_transaction+0x73/0xc00 [btrfs] [436.531] ? btrfs_attach_transaction_barrier+0x1e/0x70 [btrfs] [436.532] sync_filesystem+0x7a/0x90 [436.533] generic_shutdown_super+0x28/0x180 [436.533] kill_anon_super+0x12/0x40 [436.534] btrfs_kill_super+0x12/0x20 [btrfs] [436.534] deactivate_locked_super+0x2f/0xb0 [436.534] cleanup_mnt+0xea/0x180 [436.535] task_work_run+0x58/0xa0 [436.535] exit_to_user_mode_loop+0xed/0x480 [436.536] ? __x64_sys_umount+0x68/0x80 [436.536] do_syscall_64+0x2a5/0xf20 [436.537] entry_SYSCALL_64_after_hwframe+0x76/0x7e [436.537] RIP: 0033:0x7fe5906b6217 [436.538] Code: 0d 00 f7 (...) [436.540] RSP: 002b:00007ffcd87a61f8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [436.541] RAX: 0000000000000000 RBX: 00005618b9ecadc8 RCX: 00007fe5906b6217 [436.541] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00005618b9ecb100 [436.542] RBP: 0000000000000000 R08: 00007ffcd87a4fe0 R09: 00000000ffffffff [436.544] R10: 0000000000000103 R11: ---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.302.1).
-
Description: Vim is an open source, command line text editor. Prior to version 9.2.0435, an OS command injection vulnerability exists in Vim's :find command-line completion. When the path option contains backtick-enclosed shell commands, those commands are executed during file name completion. Because the path option lacks the P_SECURE flag, it can be set from a modeline, allowing an attacker who controls the contents of a file to execute arbitrary shell commands when the user opens that file in Vim and triggers :find completion. This issue has been patched in version 9.2.0435.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- vim > 0-0 (version in image is 9.2.0280-17.62.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: 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.302.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.37.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.74.1).
-
Description: An information disclosure issue in the zipfileInflate function in the zipfile extension in SQLite v3.51.1 and earlier allows attackers to obtain heap memory via supplying a crafted ZIP file.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libsqlite3-0 > 0-0 (version in image is 3.51.3-9.47.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:
- 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.48.4).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before accessl2cap_information_rsp() checks that cmd_len covers the fixedl2cap_info_rsp header (type + result, 4 bytes) but then readsrsp->data without verifying that the payload is present: - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8). - L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5).A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers anout-of-bounds read of adjacent skb data.Guard each data access with the required payload length check. If thepayload is too short, skip the read and let the state machine completewith safe defaults (feat_mask and remote_fixed_chan remain zero fromkzalloc), so the info timer cleanup and l2cap_conn_start() still runand the connection is not stalled.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rnbd-srv: Zero the rsp buffer before using itBefore using the data buffer to send back the response message, zero itcompletely. This prevents any stray bytes to be picked up by the clientside when there the message is exchanged between different protocolversions.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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.302.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.2.0280-17.62.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.2.0280-17.62.1).
-
Description: OpenSSH before 10.3 mishandles the authorized_keys principals option in uncommon scenarios involving a principals list in conjunction with a Certificate Authority that makes certain use of comma characters.
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.34.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_tcm: Fix NULL pointer dereferences in nexus handlingThe `tpg->tpg_nexus` pointer in the USB Target driver is dynamicallymanaged and tied to userspace configuration via ConfigFS. It can beNULL if the USB host sends requests before the nexus is fullyestablished or immediately after it is dropped.Currently, functions like `bot_submit_command()` and the datatransfer paths retrieve `tv_nexus = tpg->tpg_nexus` and immediatelydereference `tv_nexus->tvn_se_sess` without any validation. If amalicious or misconfigured USB host sends a BOT (Bulk-Only Transport)command during this race window, it triggers a NULL pointerdereference, leading to a kernel panic (local DoS).This exposes an inconsistent API usage within the module, as peerfunctions like `usbg_submit_command()` and `bot_send_bad_response()`correctly implement a NULL check for `tv_nexus` before proceeding.Fix this by bringing consistency to the nexus handling. Add themissing `if (!tv_nexus)` checks to the vulnerable BOT command andrequest processing paths, aborting the command gracefully with anerror instead of crashing the 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.302.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.302.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.302.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.302.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.2.0280-17.62.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: omap: do not register driver in probe()Commit 11a78b794496 ("ARM: OMAP: MPUIO wake updates") registers theomap_mpuio_driver from omap_mpuio_init(), which is called fromomap_gpio_probe().However, it neither makes sense to register drivers from probe()callbacks of other drivers, nor does the driver core allow registeringdrivers with a device lock already being held.The latter was revealed by commit dc23806a7c47 ("driver core: enforcedevice_lock for driver_match_device()") leading to a potential deadlockcondition described in [1].Additionally, the omap_mpuio_driver is never unregistered from thedriver core, even if the module is unloaded.Hence, register the omap_mpuio_driver from the module initcall andunregister it in module_exit().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
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: 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.302.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.74.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).
- python3 > 0-0 (version in image is 3.4.10-25.180.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.52.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: Unknown.
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: 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.51.3-9.47.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.48.4).
- 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.2.0280-17.62.1).
-
Description: http.cookies.Morsel.js_output() returns an inline inside the generated script element. Mitigation base64-encodes the cookie value to disallow escaping using cookie 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.74.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: 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.99.1).
-
Description: Unknown.
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 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.74.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.58.1).
-
Description: pyOpenSSL is a Python wrapper around the OpenSSL library. Starting in version 0.14.0 and prior to version 26.0.0, if a user provided callback to `set_tlsext_servername_callback` raised an unhandled exception, this would result in a connection being accepted. If a user was relying on this callback for any security-sensitive behavior, this could allow bypassing it. Starting in version 26.0.0, unhandled exceptions now result in rejecting the connection.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python-pyOpenSSL > 0-0 (version in image is 17.1.0-4.32.1).
-
Description: A vulnerability exists where a connection requiring TLS incorrectly reuses anexisting unencrypted connection from the same connection pool. If an initialtransfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent requestto that same host bypasses the TLS requirement and instead transmit dataunencrypted.
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.120.1).
-
Description: libcurl might in some circumstances reuse the wrong connection for SMB(S)transfers.libcurl features a pool of recent connections so that subsequent requests canreuse an existing connection to avoid overhead.When reusing a connection a range of criteria must be met. Due to a logicalerror in the code, a network transfer operation that was requested by anapplication could wrongfully reuse an existing SMB connection to the sameserver that was using a different 'share' than the new subsequent transfershould.This could in unlucky situations lead to the download of the wrong file or theupload of a file to the wrong place. When this happens, the same credentialsare used and the server name is the same.
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.120.1).
-
Description: Using libcurl, when a custom `Host:` header is first set for an HTTP requestand a second request is subsequently done using the same *easy handle* butwithout the custom `Host:` header set, the second request would use staleinformation and pass on cookies meant for the first host in the secondrequest. Leak them.
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.120.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.51.3-9.47.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 OpenSSH before 10.3, command execution can occur via shell metacharacters in a username within a command line. This requires a scenario where the username on the command line is untrusted, and also requires a non-default configurations of % in ssh_config.
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.34.1).
-
Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. Prior to 2.4.17, a network-adjacent attacker can send a crafted SNMP response to the CUPS SNMP backend that causes an out-of-bounds read of up to 176 bytes past a stack buffer. The leaked memory is converted from UTF-16 to UTF-8 and stored as printer supply description strings, which are subsequently visible to authenticated users via IPP Get-Printer-Attributes responses and the CUPS web interface. This vulnerability is fixed in 2.4.17.
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.62.1).
-
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: 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: 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 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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.2.0280-17.62.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.302.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.302.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.302.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.302.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.302.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.302.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.302.1).
-
Description: pip handles concatenated tar and ZIP files as ZIP files regardless of filename or whether a file is both a tar and ZIP file. This behavior could result in confusing installation behavior, such as installing "incorrect" files according to the filename of the archive. New behavior only proceeds with installation if the file identifies uniquely as a ZIP or tar archive, not as both.
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.74.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: af_key: zero aligned sockaddr tail in PF_KEY exportsPF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddrpayload space, so IPv6 addresses occupy 32 bytes on the wire. However,`pfkey_sockaddr_fill()` initializes only the first 28 bytes of`struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized.Not every PF_KEY message is affected. The state and policy dump buildersalready zero the whole message buffer before filling the sockaddrpayloads. Keep the fix to the export paths that still append alignedsockaddr payloads with plain `skb_put()`: - `SADB_ACQUIRE` - `SADB_X_NAT_T_NEW_MAPPING` - `SADB_X_MIGRATE`Fix those paths by clearing only the aligned sockaddr tail after`pfkey_sockaddr_fill()`.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: of: display_timing: fix refcount leak in of_get_display_timings()of_parse_phandle() returns a device_node with refcount incremented,which is stored in 'entry' and then copied to 'native_mode'. When theerror paths at lines 184 or 192 jump to 'entryfail', native_mode'srefcount is not decremented, causing a refcount leak.Fix this by changing the goto target from 'entryfail' to 'timingfail',which properly calls of_node_put(native_mode) before cleanup.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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: 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 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: 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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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 a manipulation results in unchecked return value. The attack needs to be approached locally. The exploit has been released to the public and may be used for attacks.
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 a 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 used for attacks. 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.9.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.302.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.302.1).
-
Description: Binutils objdump contains a denial-of-service vulnerability when processing a crafted binary with malformed DWARF debug information. A logic error in the handling of DWARF compilation units can result in an invalid offset_size value being used inside byte_get_little_endian, leading to an abort (SIGABRT). The issue was observed in binutils 2.44. A local attacker can trigger the crash by supplying a malicious input 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: GNU Binutils thru 2.46 readelf contains a null pointer dereference vulnerability when processing a crafted ELF binary with malformed header fields. During relocation processing, an invalid or null section pointer may be passed into display_relocations(), resulting in a segmentation fault (SIGSEGV) and abrupt termination. No evidence of memory corruption beyond the null pointer dereference, nor any possibility of code execution, was observed.
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.74.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).
- libxml2-2 > 0-0 (version in image is 2.9.4-46.99.1).
-
Description: A flaw was found in libssh where it can attempt to open arbitrary files during configuration parsing. A local attacker can exploit this by providing a malicious configuration file or when the system is misconfigured. This vulnerability could lead to a Denial of Service (DoS) by causing the system to try and access dangerous files, such as block devices or large system files, which can disrupt normal operations.
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.21.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.99.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: liquidio: Initialize netdev pointer before queue setupIn setup_nic_devices(), the netdev is allocated using alloc_etherdev_mq().However, the pointer to this structure is stored in oct->props[i].netdevonly after the calls to netif_set_real_num_rx_queues() andnetif_set_real_num_tx_queues().If either of these functions fails, setup_nic_devices() returns an errorwithout freeing the allocated netdev. Since oct->props[i].netdev is stillNULL at this point, the cleanup function liquidio_destroy_nic_device()will fail to find and free the netdev, resulting in a memory leak.Fix this by initializing oct->props[i].netdev before calling the queuesetup functions. This ensures that the netdev is properly accessible forcleanup in case of errors.Compile tested only. Issue found using a prototype static analysis tooland 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_log: account for netlink header sizeThis is a followup to an old bug fix: NLMSG_DONE needs to accountfor the netlink header size, not just the attribute size.This can result in a WARN splat + drop of the netlink message,but other than this there are no ill effects.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_expect: skip expectations in other netns via procSkip expectations that do not reside in this netns.Similar to e77e6ff502ea ("netfilter: conntrack: do not dump other netns'sconntrack entries via proc").
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm_user: fix info leak in build_report()struct xfrm_user_report is a __u8 proto field followed by a structxfrm_selector which means there is three "empty" bytes of padding, butthe padding is never zeroed before copying to userspace. Fix that up byzeroing the structure before setting individual member variables.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: core: Limit the length of unkillable synchronous timeoutsThe usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs inusbcore allow unlimited timeout durations. And since they useuninterruptible waits, this leaves open the possibility of hanging atask for an indefinitely long time, with no way to kill it short ofunplugging the target device.To prevent this sort of problem, enforce a maximum limit on the lengthof these unkillable timeouts. The limit chosen here, somewhatarbitrarily, is 60 seconds. On many systems (although not all) thisis short enough to avoid triggering the kernel's hung-task detector.In addition, clear up the ambiguity of negative timeout values bytreating them the same as 0, i.e., using the maximum allowed timeout.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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.120.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.21.1).
-
Description: OpenSSH before 10.3 can use unintended ECDSA algorithms. Listing of any ECDSA algorithm in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms is misinterpreted to mean all ECDSA algorithms.
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.34.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.180.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.302.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.99.1).
-
Description: In libexpat before 2.8.1, the computational complexity of attribute name collision checks allows a denial of service via moderately sized crafted XML input.
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.52.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.302.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 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.2.0280-17.62.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.48.4).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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.74.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: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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix data races in unix_release_sock/unix_stream_sendmsgA data-race condition has been identified in af_unix. In one data path,the write function unix_release_sock() atomically writes tosk->sk_shutdown using WRITE_ONCE. However, on the reader side,unix_stream_sendmsg() does not read it atomically. Consequently, thisissue is causing the following KCSAN splat to occur: BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28: unix_release_sock (net/unix/af_unix.c:640) unix_release (net/unix/af_unix.c:1050) sock_close (net/socket.c:659 net/socket.c:1421) __fput (fs/file_table.c:422) __fput_sync (fs/file_table.c:508) __se_sys_close (fs/open.c:1559 fs/open.c:1541) __x64_sys_close (fs/open.c:1541) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14: unix_stream_sendmsg (net/unix/af_unix.c:2273) __sock_sendmsg (net/socket.c:730 net/socket.c:745) ____sys_sendmsg (net/socket.c:2584) __sys_sendmmsg (net/socket.c:2638 net/socket.c:2724) __x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x01 -> 0x03The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.")addressed a comparable issue in the past regarding sk->sk_shutdown.However, it overlooked resolving this particular data path.This patch only offending unix_stream_sendmsg() function, since theother reads seem to be protected by unix_state_lock() as discussed in
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.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.302.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: 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.302.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.302.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.302.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.302.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.302.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).
- python3 > 0-0 (version in image is 3.4.10-25.180.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:nfc: nci: complete pending data exchange on device closeIn nci_close_device(), complete any pending data exchange beforeclosing. The data exchange callback (e.g.rawsock_data_exchange_complete) holds a socket reference.NIPA occasionally hits this leak:unreferenced object 0xff1100000f435000 (size 2048): comm "nci_dev", pid 3954, jiffies 4295441245 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc ec2b3c5): __kmalloc_noprof+0x4db/0x730 sk_prot_alloc.isra.0+0xe4/0x1d0 sk_alloc+0x36/0x760 rawsock_create+0xd1/0x540 nfc_sock_create+0x11f/0x280 __sock_create+0x22d/0x630 __sys_socket+0x115/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0x117/0xfc0 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.302.1).
-
Description: OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.
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.34.1).
-
Description: libexpat before 2.8.0 uses insufficient entropy, and thus hash flooding can occur via a crafted XML document.
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.52.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.302.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Reinit dev->spinlock between attachments to low-level drivers`struct comedi_device` is the main controlling structure for a COMEDIdevice created by the COMEDI subsystem. It contains a member `spinlock`containing a spin-lock that is initialized by the COMEDI subsystem, butis reserved for use by a low-level driver attached to the COMEDI device(at least since commit 25436dc9d84f ("Staging: comedi: remove RTcode")).Some COMEDI devices (those created on initialization of the COMEDIsubsystem when the "comedi.comedi_num_legacy_minors" parameter isnon-zero) can be attached to different low-level drivers over theirlifetime using the `COMEDI_DEVCONFIG` ioctl command. This can result ininconsistent lock states being reported when there is a mismatch in thespin-lock locking levels used by each low-level driver to which theCOMEDI device has been attached. Fix it by reinitializing`dev->spinlock` before calling the low-level driver's `attach` functionpointer if `CONFIG_LOCKDEP` is 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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rt2x00usb: fix devres lifetimeUSB drivers bind to USB interfaces and any device managed resourcesshould have their lifetime tied to the interface rather than parent USBdevice. This avoids issues like memory leaks when drivers are unboundwithout their devices being physically disconnected (e.g. on probedeferral or configuration changes).Fix the USB anchor lifetime so that it is released on driver unbind.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: A flaw was found in libssh. A remote attacker, by controlling client configuration files or known_hosts files, could craft specific hostnames that when processed by the `match_pattern()` function can lead to inefficient regular expression backtracking. This can cause timeouts and resource exhaustion, resulting in a Denial of Service (DoS) for the client.
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.21.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.302.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.68.1).
- 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: 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.74.1).
- 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.68.1).
- 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.68.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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: 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.68.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: The resolve_redirects function in sessions.py in requests 2.1.0 through 2.5.3 allows remote attackers to conduct session fixation attacks via a cookie without a host value in a redirect.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python-requests > 0-0 (version in image is 2.24.0-8.26.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.68.1).
-
Description: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2017-11543. Reason: This candidate is a duplicate of CVE-2017-11543. Notes: All CVE users should reference CVE-2017-11543 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage
Packages affected:
- sles-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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.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.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: fsl: qbman: fix race condition in qman_destroy_fqWhen QMAN_FQ_FLAG_DYNAMIC_FQID is set, there's a race condition betweenfq_table[fq->idx] state and freeing/allocating from the pool andWARN_ON(fq_table[fq->idx]) in qman_create_fq() gets triggered.Indeed, we can have: Thread A Thread B qman_destroy_fq() qman_create_fq() qman_release_fqid() qman_shutdown_fq() gen_pool_free() -- At this point, the fqid is available again -- qman_alloc_fqid() -- so, we can get the just-freed fqid in thread B -- fq->fqid = fqid; fq->idx = fqid * 2; WARN_ON(fq_table[fq->idx]); fq_table[fq->idx] = fq; fq_table[fq->idx] = NULL;And adding some logs between qman_release_fqid() andfq_table[fq->idx] = NULL makes the WARN_ON() trigger a lot more.To prevent that, ensure that fq_table[fq->idx] is set to NULL beforegen_pool_free() is called by using smp_wmb().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.302.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptrace: slightly saner 'get_dumpable()' logicThe 'dumpability' of a task is fundamentally about the memory image ofthe task - the concept comes from whether it can core dump or not - andmakes no sense when you don't have an associated mm.And almost all users do in fact use it only for the case where the taskhas a mm pointer.But we have one odd special case: ptrace_may_access() uses 'dumpable' tocheck various other things entirely independently of the MM (typicallyexplicitly using flags like PTRACE_MODE_READ_FSCREDS). Including forthreads that no longer have a VM (and maybe never did, like most kernelthreads).It's not what this flag was designed for, but it is what it is.The ptrace code does check that the uid/gid matches, so you do have tobe uid-0 to see kernel thread details, but this means that thetraditional "drop capabilities" model doesn't make any difference forthis all.Make it all make a *bit* more sense by saying that if you don't have aMM pointer, we'll use a cached "last dumpability" flag if the threadever had a MM (it will be zero for kernel threads since it is neverset), and require a proper CAP_SYS_PTRACE capability to override.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.307.1 (version in image is 4.12.14-122.302.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).