-
Description: BlueZ HID over GATT Profile Improper Access Control Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of BlueZ. Authentication is not required to exploit this vulnerability.The specific flaw exists within the implementation of the HID over GATT Profile. The issue results from the lack of authorization prior to allowing access to functionality. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-25177.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.163.1 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Also unshare DATA/RESPONSE packets when paged frags are presentThe DATA-packet handler in rxrpc_input_call_event() and the RESPONSEhandler in rxrpc_verify_response() copy the skb to a linear one beforecalling into the security ops only when skb_cloned() is true. An skbthat is not cloned but still carries externally-owned paged fragments(e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via__ip_append_data, or a chained skb_has_frag_list()) falls through tothe in-place decryption path, which binds the frag pages directly intothe AEAD/skcipher SGL via skb_to_sgvec().Extend the gate to also unshare when skb_has_frag_list() orskb_has_shared_frag() is true. This catches the splice-loopback vectorand other externally-shared frag sources while preserving thezero-copy fast path for skbs whose frags are kernel-private (e.g. NICpage_pool RX, GRO). The OOM/trace handling already in place is reused.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.163.1 (version in image is 5.14.21-150500.55.149.1).
-
Description: Unknown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.163.1 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.56.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: fix undersized l_iclog_roundoff valuesIf the superblock doesn't list a log stripe unit, we set the incore logroundoff value to 512. This leads to corrupt logs and unmountablefilesystems in generic/617 on a disk with 4k physical sectors...XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1cXFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197.XFS (sda1): failed to locate log tailXFS (sda1): log mount/recovery failed: error -74XFS (sda1): log mount failedXFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1cXFS (sda1): Ending clean mount...on the current xfsprogs for-next which has a broken mkfs. xfs_infoshows this...meta-data=/dev/sda1 isize=512 agcount=4, agsize=644992 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=1data = bsize=4096 blocks=2579968, imaxpct=25 = sunit=0 swidth=0 blksnaming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1log =internal log bsize=4096 blocks=16384, version=2 = sectsz=4096 sunit=0 blks, lazy-count=1realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=268435456 extents = zoned=0 start=0 reserved=0...observe that the log section has sectsz=4096 sunit=0, which meansthat the roundoff factor is 512, not 4096 as you'd expect. We shouldfix mkfs not to generate broken filesystems, but anyone can fuzz theondisk superblock so we should be more cautious. I think the inadequatelogic predates commit a6a65fef5ef8d0, but that's clearly going torequire a different backport.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: move wake reason storage into validated event handlershci_store_wake_reason() is called from hci_event_packet() immediatelyafter stripping the HCI event header but before hci_event_func()enforces the per-event minimum payload length from hci_ev_table.This means a short HCI event frame can reach bacpy() before any boundscheck runs.Rather than duplicating skb parsing and per-event length checks insidehci_store_wake_reason(), move wake-address storage into the individualevent handlers after their existing event-length validation hassucceeded. Convert hci_store_wake_reason() into a small helper that onlystores an already-validated bdaddr while the caller holds hci_dev_lock().Use the same helper after hci_event_func() with a NULL address topreserve the existing unexpected-wake fallback semantics when novalidated event handler records a wake address.Annotate the helper with __must_hold(&hdev->lock) and addlockdep_assert_held(&hdev->lock) so future call paths keep the lockcontract explicit.Call the helper from hci_conn_request_evt(), hci_conn_complete_evt(),hci_sync_conn_complete_evt(), le_conn_complete_evt(),hci_le_adv_report_evt(), hci_le_ext_adv_report_evt(),hci_le_direct_adv_report_evt(), hci_le_pa_sync_established_evt(), andhci_le_past_received_evt().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.43.2).
- google-guest-agent > 0-0 (version in image is 20250506.01-150000.1.63.1).
-
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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hsr: avoid potential out-of-bound access in fill_frame_info()syzbot is able to feed a packet with 14 bytes, pretendingit is a vlan one.Since fill_frame_info() is relying on skb->mac_len already,extend the check to cover this case.BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline] BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 fill_frame_info net/hsr/hsr_forward.c:709 [inline] hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606 __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434 dev_queue_xmit include/linux/netdevice.h:3168 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3146 [inline] packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1323 [inline] alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881 packet_alloc_skb net/packet/af_packet.c:2995 [inline] packet_snd net/packet/af_packet.c:3089 [inline] packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOTIn qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumedto be either root or ingress. This assumption is bogus since it's validto create egress qdiscs with major handle ffff:Budimir Markovic found that for qdiscs like DRR that maintain an activeclass list, it will cause a UAF with a dangling class pointer.In 066a3b5b2346, the concern was to avoid iterating over the ingressqdisc since its parent is itself. The proper fix is to stop when parentTC_H_ROOT is reached because the only way to retrieve ingress is when ahierarchy which does not contain a ffff: major handle call intoqdisc_lookup with TC_H_MAJ(TC_H_ROOT).In the scenario where major ffff: is an egress qdisc in any of the treelevels, the updates will also propagate to TC_H_ROOT, which then theiteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: sync_linked_regs() must preserve subreg_defRange propagation must not affect subreg_def marks, otherwise thefollowing example is rewritten by verifier incorrectly whenBPF_F_TEST_RND_HI32 flag is set: 0: call bpf_ktime_get_ns call bpf_ktime_get_ns 1: r0 &= 0x7fffffff after verifier r0 &= 0x7fffffff 2: w1 = w0 rewrites w1 = w0 3: if w0 < 10 goto +0 --------------> r11 = 0x2f5674a6 (r) 4: r1 >>= 32 r11 <<= 32 (r) 5: r0 = r1 r1 |= r11 (r) 6: exit; if w0 < 0xa goto pc+0 r1 >>= 32 r0 = r1 exit(or zero extension of w1 at (2) is missing for architectures that require zero extension for upper register half).The following happens w/o this patch:- r0 is marked as not a subreg at (0);- w1 is marked as subreg at (2);- w1 subreg_def is overridden at (3) by copy_register_state();- w1 is read at (5) but mark_insn_zext() does not mark (2) for zero extension, because w1 subreg_def is not set;- because of BPF_F_TEST_RND_HI32 flag verifier inserts random value for hi32 bits of (2) (marked (r));- this random value is read at (5).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: add missing range check in bitmap_ip_uadtWhen tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists,the values of ip and ip_to are slightly swapped. Therefore, the range checkfor ip should be done later, but this part is missing and it seems that thevulnerability occurs.So we should add missing range checks and remove unnecessary range checks.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \ --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \ 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp's timer handler function causes problems.To fix this problem, let's hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Properly hide first-in-list PCIe extended capabilityThere are cases where a PCIe extended capability should be hidden fromthe user. For example, an unknown capability (i.e., capability with IDgreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionallychosen to be hidden from the user.Hiding a capability is done by virtualizing and modifying the 'NextCapability Offset' field of the previous capability so it points to thecapability after the one that should be hidden.The special case where the first capability in the list should be hiddenis handled differently because there is no previous capability that canbe modified. In this case, the capability ID and version are zeroedwhile leaving the next pointer intact. This hides the capability andleaves an anchor for the rest of the capability list.However, today, hiding the first capability in the list is not doneproperly if the capability is unknown, as structvfio_pci_core_device->pci_config_map is set to the capability ID duringinitialization but the capability ID is not properly checked later whenused in vfio_config_do_rw(). This leads to the following warning [1] andto an out-of-bounds access to ecap_perms array.Fix it by checking cap_id in vfio_config_do_rw(), and if it is greaterthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for directread only access instead of the ecap_perms array.Note that this is safe since the above is the only case where cap_id canexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, whichare already checked before).[1]WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1(snip)Call Trace: ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: inet6: do not leave a dangling sk pointer in inet6_create()sock_init_data() attaches the allocated sk pointer to the provided sockobject. If inet6_create() fails later, the sk object is released, but thesock object retains the dangling sk pointer, which may cause use-after-freelater.Clear the sock sk pointer on error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: inet: do not leave a dangling sk pointer in inet_create()sock_init_data() attaches the allocated sk object to the provided sockobject. If inet_create() fails later, the sk object is freed, but thesock object retains the dangling pointer, which may create use-after-freelater.Clear the sk pointer in the sock object on error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()sock_init_data() attaches the allocated sk object to the provided sockobject. If ieee802154_create() fails later, the allocated sk object isfreed, but the dangling pointer remains in the provided sock object, whichmay allow use-after-free.Clear the sk pointer in the sock object on error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry()Syzbot reported that when searching for records in a directory where theinode's i_size is corrupted and has a large value, memory access outsidethe folio/page range may occur, or a use-after-free bug may be detected ifKASAN is enabled.This is because nilfs_last_byte(), which is called by nilfs_find_entry()and others to calculate the number of valid bytes of directory data in apage from i_size and the page index, loses the upper 32 bits of the 64-bitsize information due to an inappropriate type of local variable to whichthe i_size value is assigned.This caused a large byte offset value due to underflow in the end addresscalculation in the calling nilfs_find_entry(), resulting in memory accessthat exceeds the folio/page size.Fix this issue by changing the type of the local variable causing the bitloss from "unsigned int" to "u64". The return value of nilfs_last_byte()is also of type "unsigned int", but it is truncated so as not to exceedPAGE_SIZE and no bit loss occurs, so no change is required.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: x_tables: fix LED ID check in led_tg_check()Syzbot has reported the following BUG detected by KASAN:BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70Read of size 1 at addr ffff8881022da0c8 by task repro/5879...Call Trace: dump_stack_lvl+0x241/0x360 ? __pfx_dump_stack_lvl+0x10/0x10 ? __pfx__printk+0x10/0x10 ? _printk+0xd5/0x120 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 print_report+0x169/0x550 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x45f/0x530 ? __phys_addr+0xba/0x170 ? strlen+0x58/0x70 kasan_report+0x143/0x180 ? strlen+0x58/0x70 strlen+0x58/0x70 kstrdup+0x20/0x80 led_tg_check+0x18b/0x3c0 xt_check_target+0x3bb/0xa40 ? __pfx_xt_check_target+0x10/0x10 ? stack_depot_save_flags+0x6e4/0x830 ? nft_target_init+0x174/0xc30 nft_target_init+0x82d/0xc30 ? __pfx_nft_target_init+0x10/0x10 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? rcu_is_watching+0x15/0xb0 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? __kmalloc_noprof+0x21a/0x400 nf_tables_newrule+0x1860/0x2980 ? __pfx_nf_tables_newrule+0x10/0x10 ? __nla_parse+0x40/0x60 nfnetlink_rcv+0x14e5/0x2ab0 ? __pfx_validate_chain+0x10/0x10 ? __pfx_nfnetlink_rcv+0x10/0x10 ? __lock_acquire+0x1384/0x2050 ? netlink_deliver_tap+0x2e/0x1b0 ? __pfx_lock_release+0x10/0x10 ? netlink_deliver_tap+0x2e/0x1b0 netlink_unicast+0x7f8/0x990 ? __pfx_netlink_unicast+0x10/0x10 ? __virt_addr_valid+0x183/0x530 ? __check_object_size+0x48e/0x900 netlink_sendmsg+0x8e4/0xcb0 ? __pfx_netlink_sendmsg+0x10/0x10 ? aa_sock_msg_perm+0x91/0x160 ? __pfx_netlink_sendmsg+0x10/0x10 __sock_sendmsg+0x223/0x270 ____sys_sendmsg+0x52a/0x7e0 ? __pfx_____sys_sendmsg+0x10/0x10 __sys_sendmsg+0x292/0x380 ? __pfx___sys_sendmsg+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? exc_page_fault+0x590/0x8c0 ? do_syscall_64+0xb6/0x230 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f... Since an invalid (without '\0' byte at all) byte sequence may be passedfrom userspace, add an extra check to ensure that such a sequence isrejected as possible ID and so never passed to 'kstrdup()' and further.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: defer final 'struct net' free in netns dismantleIlya reported a slab-use-after-free in dst_destroy [1]Issue is in xfrm6_net_init() and xfrm4_net_init() :They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops.But net structure might be freed before all the dst callbacks arecalled. So when dst_destroy() calls later :if (dst->ops->destroy) dst->ops->destroy(dst);dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed.See a relevant issue fixed in :ac888d58869b ("net: do not delay dst_entries_add() in dst_release()")A fix is to queue the 'struct net' to be freed after oneanother cleanup_net() round (and existing rcu_barrier())[1]BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112)Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0Dec 03 05:46:18 kernel:CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014Call Trace: dump_stack_lvl (lib/dump_stack.c:124)print_address_description.constprop.0 (mm/kasan/report.c:378)? dst_destroy (net/core/dst.c:112)print_report (mm/kasan/report.c:489)? dst_destroy (net/core/dst.c:112)? kasan_addr_to_slab (mm/kasan/common.c:37)kasan_report (mm/kasan/report.c:603)? dst_destroy (net/core/dst.c:112)? rcu_do_batch (kernel/rcu/tree.c:2567)dst_destroy (net/core/dst.c:112)rcu_do_batch (kernel/rcu/tree.c:2567)? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491)? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406)rcu_core (kernel/rcu/tree.c:2825)handle_softirqs (kernel/softirq.c:554)__irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637)irq_exit_rcu (kernel/softirq.c:651)sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049) asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702)RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743)Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835dR10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148)? cpuidle_idle_call (kernel/sched/idle.c:186)default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118)cpuidle_idle_call (kernel/sched/idle.c:186)? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168)? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848)? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406)? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59)do_idle (kernel/sched/idle.c:326)cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1))start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282)? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232)? soft_restart_cpu (arch/x86/kernel/head_64.S:452)common_startup_64 (arch/x86/kernel/head_64.S:414) Dec 03 05:46:18 kernel:Allocated by task 12184:kasan_save_stack (mm/kasan/common.c:48)kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69)__kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141)copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480)create_new_namespaces---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: GNU GRUB (aka GRUB2) through 2.12 has a heap-based buffer overflow in fs/hfs.c via crafted sblock data in an HFS filesystem.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.65.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fuse: reject oversized dirents in page cachefuse_add_dirent_to_cache() computes a serialized dirent size from theserver-controlled namelen field and copies the dirent into a singlepage-cache page. The existing logic only checks whether the dirent fitsin the remaining space of the current page and advances to a fresh pageif not. It never checks whether the dirent itself exceeds PAGE_SIZE.As a result, a malicious FUSE server can return a dirent withnamelen=4095, producing a serialized record size of 4120 bytes. On 4 KiBpage systems this causes memcpy() to overflow the cache page by 24 bytesinto the following kernel page.Reject dirents that cannot fit in a single page before copying them intothe readdir cache.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: usbtmc: Flush anchored URBs in usbtmc_releaseWhen calling usbtmc_release, pending anchored URBs must be flushed orkilled to prevent use-after-free errors (e.g. in the HCD givebackpath). Call usbtmc_draw_down() to allow anchored URBs to be completed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: strictly check for maximum number of actionsThe maximum number of flowtable hardware offload actions in IPv6 is:* ethernet mangling (4 payload actions, 2 for each ethernet address)* SNAT (4 payload actions)* DNAT (4 payload actions)* Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ.* Redirect (1 action)Which makes 17, while the maximum is 16. But act_ct supports for tunnelsactions too. Note that payload action operates at 32-bit word level, somangling an IPv6 address takes 4 payload actions.Update flow_action_entry_next() calls to check for the maximum number ofsupported actions.While at it, rise the maximum number of actions per flow from 16 to 24so this works fine with IPv6 setups.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.163.1 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- vim > 0-0 (version in image is 9.2.0280-150500.20.46.1).
-
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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. In versions on the 4.x branch prior to version 4.0.5, when parsing compact JWS or JWE input, Go JOSE could use excessive memory. The code used strings.Split(token, ".") to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of `.` characters. An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service. Version 4.0.5 fixes this issue. As a workaround, applications could pre-validate that payloads passed to Go JOSE do not contain an excessive number of `.` characters.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- containerd > 0-0 (version in image is 1.7.29-150000.132.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSGThe GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrementsbc_ackers on every inbound group ACK, even when the same member hasalready acknowledged the current broadcast round.Because bc_ackers is a u16, a duplicate ACK received after the lastlegitimate ACK wraps the counter to 65535. Once wrapped,tipc_group_bc_cong() keeps reporting congestion and later groupbroadcasts on the affected socket stay blocked until the group isrecreated.Fix this by ignoring duplicate or stale ACKs before touching bc_acked orbc_ackers. This makes repeated GRP_ACK_MSG handling idempotent andprevents the underflow path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.56.1).
-
Description: Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. Prior to 4.1.4 and 3.0.5, decrypting a JSON Web Encryption (JWE) object will panic if the alg field indicates a key wrapping algorithm (one ending in KW, with the exception of A128GCMKW, A192GCMKW, and A256GCMKW) and the encrypted_key field is empty. The panic happens when cipher.KeyUnwrap() in key_wrap.go attempts to allocate a slice with a zero or negative length based on the length of the encrypted_key. This code path is reachable from ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() followed by Decrypt() on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected. This panic is also reachable by calling cipher.KeyUnwrap() directly with any ciphertext parameter less than 16 bytes long, but calling this function directly is less common. Panics can lead to denial of service. This vulnerability is fixed in 4.1.4 and 3.0.5.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- containerd > 0-0 (version in image is 1.7.29-150000.132.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- openssh > 0-0 (version in image is 8.4p1-150300.3.57.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- glibc > 0-0 (version in image is 2.31-150300.98.1).
-
Description: A flaw was found in gnutls. A remote attacker could exploit an issue in the Datagram Transport Layer Security (DTLS) packet reordering logic. The comparator function, responsible for ordering DTLS packets by sequence numbers, did not correctly handle packets with duplicate sequence numbers. This could lead to unstable packet ordering or undefined behavior, resulting in a denial of service.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.56.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
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 == 15.5 (version in image is 15.5-150500.61.4.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.163.1 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- liblzma5 > 0-0 (version in image is 5.2.3-150000.4.7.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ntb: ntb_hw_switchtec: Fix array-index-out-of-bounds accessNumber of MW LUTs depends on NTB configuration and can be set to MAX_MWS,This patch protects against invalid index out of bounds access to mw_sizesWhen invalid access print message to user that configuration is not valid.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Fix use-after-free of kernel socket in cleanup_bearer().syzkaller reported a use-after-free of UDP kernel socketin cleanup_bearer() without repro. [0][1]When bearer_disable() calls tipc_udp_disable(), cleanupof the UDP kernel socket is deferred by work callingcleanup_bearer().tipc_exit_net() waits for such works to finish by checkingtipc_net(net)->wq_count. However, the work decrements thecount too early before releasing the kernel socket,unblocking cleanup_net() and resulting in use-after-free.Let's move the decrement after releasing the socket incleanup_bearer().[0]:ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at sk_alloc+0x438/0x608 inet_create+0x4c8/0xcb0 __sock_create+0x350/0x6b8 sock_create_kern+0x58/0x78 udp_sock_create4+0x68/0x398 udp_sock_create+0x88/0xc8 tipc_udp_enable+0x5e8/0x848 __tipc_nl_bearer_enable+0x84c/0xed8 tipc_nl_bearer_enable+0x38/0x60 genl_family_rcv_msg_doit+0x170/0x248 genl_rcv_msg+0x400/0x5b0 netlink_rcv_skb+0x1dc/0x398 genl_rcv+0x44/0x68 netlink_unicast+0x678/0x8b0 netlink_sendmsg+0x5e4/0x898 ____sys_sendmsg+0x500/0x830[1]:BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [inline] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [inline] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244Uninit was created at: slab_free_hook mm/slub.c:2269 [inline] slab_free mm/slub.c:4580 [inline] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [inline] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfaHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014Workqueue: events cleanup_bearer
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix OOB reads parsing symlink error responseWhen a CREATE returns STATUS_STOPPED_ON_SYMLINK, smb2_check_message()returns success without any length validation, leaving the symlinkparsers as the only defense against an untrusted server.symlink_data() walks SMB 3.1.1 error contexts with the loop test "p ErrorId at offset 4 and p->ErrorDataLength at offset0. When the server-controlled ErrorDataLength advances p to within 1-7bytes of end, the next iteration will read past it. When the matchingcontext is found, sym->SymLinkErrorTag is read at offset 4 fromp->ErrorContextData with no check that the symlink header itself fits.smb2_parse_symlink_response() then bounds-checks the substitute nameusing SMB2_SYMLINK_STRUCT_SIZE as the offset of PathBuffer fromiov_base. That value is computed as sizeof(smb2_err_rsp) +sizeof(smb2_symlink_err_rsp), which is correct only whenErrorContextCount == 0.With at least one error context the symlink data sits 8 bytes deeper,and each skipped non-matching context shifts it further by 8 +ALIGN(ErrorDataLength, 8). The check is too short, allowing thesubstitute name read to run past iov_len. The out-of-bound heap bytesare UTF-16-decoded into the symlink target and returned to userspace viareadlink(2).Fix this all up by making the loops test require the full context headerto fit, rejecting sym if its header runs past end, and bound thesubstitute name against the actual position of sym->PathBuffer ratherthan a fixed offset.Because sub_offs and sub_len are 16bits, the pointer math will notoverflow here with the new greater-than.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.56.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: fix ordering of qlen adjustmentChanges to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen_before_ a call to said function because otherwise it may fail to notifyparent qdiscs when the child is about to become empty.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: prevent use-after-free due to open_cached_dir error pathsIf open_cached_dir() encounters an error parsing the lease from theserver, the error handling may race with receiving a lease break,resulting in open_cached_dir() freeing the cfid while the queued work ispending.Update open_cached_dir() to drop refs rather than directly freeing thecfid.Have cached_dir_lease_break(), cfids_laundromat_worker(), andinvalidate_all_cached_dirs() clear has_lease immediately while stillholding cfids->cfid_list_lock, and then use this to also simplify thereference counting in cfids_laundromat_worker() andinvalidate_all_cached_dirs().Fixes this KASAN splat (which manually injects an error and lease breakin open_cached_dir()):==================================================================BUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0Read of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020Workqueue: cifsiod smb2_cached_lease_breakCall Trace: dump_stack_lvl+0x77/0xb0 print_report+0xce/0x660 kasan_report+0xd3/0x110 smb2_cached_lease_break+0x27/0xb0 process_one_work+0x50a/0xc50 worker_thread+0x2ba/0x530 kthread+0x17c/0x1c0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 Allocated by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 open_cached_dir+0xa7d/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x51/0x70 kfree+0x174/0x520 open_cached_dir+0x97f/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7eLast potentially related work creation: kasan_save_stack+0x33/0x60 __kasan_record_aux_stack+0xad/0xc0 insert_work+0x32/0x100 __queue_work+0x5c9/0x870 queue_work_on+0x82/0x90 open_cached_dir+0x1369/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe buggy address belongs to the object at ffff88811cc24c00 which belongs to the cache kmalloc-1k of size 1024The buggy address is located 16 bytes inside of freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free of signing keyCustomers have reported use-after-free in @ses->auth_key.response withSMB2.1 + sign mounts which occurs due to following race:task A task Bcifs_mount() dfs_mount_share() get_session() cifs_mount_get_session() cifs_send_recv() cifs_get_smb_ses() compound_send_recv() cifs_setup_session() smb2_setup_request() kfree_sensitive() smb2_calc_signature() crypto_shash_setkey() *UAF*Fix this by ensuring that we have a valid @ses->auth_key.response bychecking whether @ses->ses_status is SES_GOOD or SES_EXITING with@ses->ses_lock held. After commit 24a9799aa8ef ("smb: client: fix UAFin smb2_reconnect_server()"), we made sure to call ->logoff() onlywhen @ses was known to be good (e.g. valid ->auth_key.response), soit's safe to access signing key when @ses->ses_status == SES_EXITING.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: array-index-out-of-bounds fix in dtReadFirstThe value of stbl can be sometimes out of bounds dueto a bad filesystem. Added a check with appopriate returnof error code in that case.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix use after free on unloadSystem crash is observed with stack trace warning of use afterfree. There are 2 signals to tell dpc_thread to terminate (UNLOADINGflag and kthread_stop).On setting the UNLOADING flag when dpc_thread happens to run at the timeand sees the flag, this causes dpc_thread to exit and clean upitself. When kthread_stop is called for final cleanup, this causes useafter free.Remove UNLOADING signal to terminate dpc_thread. Use the kthread_stopas the main signal to exit dpc_thread.[596663.812935] kernel BUG at mm/slub.c:294![596663.812950] invalid opcode: 0000 [#1] SMP PTI[596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1[596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012[596663.812974] RIP: 0010:__slab_free+0x17d/0x360...[596663.813008] Call Trace:[596663.813022] ? __dentry_kill+0x121/0x170[596663.813030] ? _cond_resched+0x15/0x30[596663.813034] ? _cond_resched+0x15/0x30[596663.813039] ? wait_for_completion+0x35/0x190[596663.813048] ? try_to_wake_up+0x63/0x540[596663.813055] free_task+0x5a/0x60[596663.813061] kthread_stop+0xf3/0x100[596663.813103] qla2x00_remove_one+0x284/0x440 [qla2xxx]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: sg: Fix slab-use-after-free read in sg_release()Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN:BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30kernel/locking/lockdep.c:5838__mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407In sg_release(), the function kref_put(&sfp->f_ref, sg_remove_sfp) iscalled before releasing the open_rel_lock mutex. The kref_put() call maydecrement the reference count of sfp to zero, triggering its cleanupthrough sg_remove_sfp(). This cleanup includes scheduling deferred workvia sg_remove_sfp_usercontext(), which ultimately frees sfp.After kref_put(), sg_release() continues to unlock open_rel_lock and mayreference sfp or sdp. If sfp has already been freed, this results in aslab-use-after-free error.Move the kref_put(&sfp->f_ref, sg_remove_sfp) call after unlocking theopen_rel_lock mutex. This ensures: - No references to sfp or sdp occur after the reference count is decremented. - Cleanup functions such as sg_remove_sfp() and sg_remove_sfp_usercontext() can safely execute without impacting the mutex handling in sg_release().The fix has been tested and validated by syzbot. This patch closes thebug reported at the following syzkaller link and ensures propersequencing of resource cleanup and mutex operations, eliminating therisk of use-after-free errors in sg_release().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: hi311x: hi3110_can_ist(): fix potential use-after-freeThe commit a22bd630cfff ("can: hi311x: do not report txerr and rxerrduring bus-off") removed the reporting of rxerr and txerr even in caseof correct operation (i. e. not bus-off).The error count information added to the CAN frame after netif_rx() isa potential use after free, since there is no guarantee that the skbis in the same state. It might be freed or reused.Fix the issue by postponing the netif_rx() call in case of txerr andrxerr reporting.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix race between element replace and close()Element replace (with a socket different from the one stored) may racewith socket's close() link popping & unlinking. __sock_map_delete()unconditionally unrefs the (wrong) element:// set map[0] = s0map_update_elem(map, 0, s0)// drop fd of s0close(s0) sock_map_close() lock_sock(sk) (s0!) sock_map_remove_links(sk) link = sk_psock_link_pop() sock_map_unlink(sk, link) sock_map_delete_from_link // replace map[0] with s1 map_update_elem(map, 0, s1) sock_map_update_elem (s1!) lock_sock(sk) sock_map_update_common psock = sk_psock(sk) spin_lock(&stab->lock) osk = stab->sks[idx] sock_map_add_link(..., &stab->sks[idx]) sock_map_unref(osk, &stab->sks[idx]) psock = sk_psock(osk) sk_psock_put(sk, psock) if (refcount_dec_and_test(&psock)) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) unlock_sock(sk) __sock_map_delete spin_lock(&stab->lock) sk = *psk // s1 replaced s0; sk == s1 if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch sk = xchg(psk, NULL) if (sk) sock_map_unref(sk, psk) // unref s1; sks[idx] will dangle psock = sk_psock(sk) sk_psock_put(sk, psock) if (refcount_dec_and_test()) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) release_sock(sk)Then close(map) enqueues bpf_map_free_deferred, which finally callssock_map_free(). This results in some refcount_t warnings along witha KASAN splat [1].Fix __sock_map_delete(), do not allow sock_map_unref() on elements thatmay have been replaced.[1]:BUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014Workqueue: events_unbound bpf_map_free_deferredCall Trace: dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 kasan_check_range+0x10f/0x1e0 sock_map_free+0x10e/0x330 bpf_map_free_deferred+0x173/0x320 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 Allocated by task 1202: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 unix_create1+0x88/0x8a0 unix_create+0xc5/0x180 __sock_create+0x241/0x650 __sys_socketpair+0x1ce/0x420 __x64_sys_socketpair+0x92/0x100 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 46: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 sk_psock_destroy+0x73e/0xa50 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30The bu---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix use-after-free when COWing tree bock and tracing is enabledWhen a COWing a tree block, at btrfs_cow_block(), and we have thetracepoint trace_btrfs_cow_block() enabled and preemption is also enabled(CONFIG_PREEMPT=y), we can trigger a use-after-free in the COWed extentbuffer while inside the tracepoint code. This is because in some pathsthat call btrfs_cow_block(), such as btrfs_search_slot(), we are holdingthe last reference on the extent buffer @buf so btrfs_force_cow_block()drops the last reference on the @buf extent buffer when it callsfree_extent_buffer_stale(buf), which schedules the release of the extentbuffer with RCU. This means that if we are on a kernel with preemption,the current task may be preempted before calling trace_btrfs_cow_block()and the extent buffer already released by the time trace_btrfs_cow_block()is called, resulting in a use-after-free.Fix this by moving the trace_btrfs_cow_block() from btrfs_cow_block() tobtrfs_force_cow_block() before the COWed extent buffer is freed.This also has a side effect of invoking the tracepoint in the tree defragcode, at defrag.c:btrfs_realloc_node(), since btrfs_force_cow_block() iscalled there, but this is fine and it was actually missing there.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: imm: Fix use-after-free bug caused by unfinished delayed workThe delayed work item 'imm_tq' is initialized in imm_attach() andscheduled via imm_queuecommand() for processing SCSI commands. When theIMM parallel port SCSI host adapter is detached through imm_detach(),the imm_struct device instance is deallocated.However, the delayed work might still be pending or executingwhen imm_detach() is called, leading to use-after-free bugswhen the work function imm_interrupt() accesses the alreadyfreed imm_struct memory.The race condition can occur as follows:CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck()imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USEAdd disable_delayed_work_sync() in imm_detach() to guarantee propercancellation of the delayed work item before imm_struct is deallocated.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/sva: invalidate stale IOTLB entries for kernel address spaceIntroduce a new IOMMU interface to flush IOTLB paging cache entries forthe CPU kernel address space. This interface is invoked from the x86architecture code that manages combined user and kernel page tables,specifically before any kernel page table page is freed and reused.This addresses the main issue with vfree() which is a common occurrenceand can be triggered by unprivileged users. While this resolves theprimary problem, it doesn't address some extremely rare case related tomemory unplug of memory that was present as reserved memory at boot, whichcannot be triggered by unprivileged users. The discussion can be found atthe link below.Enable SVA on x86 architecture since the IOMMU can now receivenotification to flush the paging cache before freeing the CPU kernel pagetable pages.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:espintcp: Fix race condition in espintcp_close()This issue was discovered during a code audit.After cancel_work_sync() is called from espintcp_close(),espintcp_tx_work() can still be scheduled from paths such asthe Delayed ACK handler or ksoftirqd.As a result, the espintcp_tx_work() worker may dereference afreed espintcp ctx or sk.The following is a simple race scenario: cpu0 cpu1 espintcp_close() cancel_work_sync(&ctx->work); espintcp_write_space() schedule_work(&ctx->work);To prevent this race condition, cancel_work_sync() isreplaced with disable_work_sync().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tls: Fix race condition in tls_sw_cancel_work_tx()This issue was discovered during a code audit.After cancel_delayed_work_sync() is called from tls_sk_proto_close(),tx_work_handler() can still be scheduled from paths such as theDelayed ACK handler or ksoftirqd.As a result, the tx_work_handler() worker may dereference a freedTLS object.The following is a simple race scenario: cpu0 cpu1tls_sk_proto_close() tls_sw_cancel_work_tx() tls_write_space() tls_sw_write_space() if (!test_and_set_bit(BIT_TX_SCHEDULED, &tx_ctx->tx_bitmask)) set_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask); cancel_delayed_work_sync(&ctx->tx_work.work); schedule_delayed_work(&tx_ctx->tx_work.work, 0);To prevent this race condition, cancel_delayed_work_sync() isreplaced with disable_delayed_work_sync().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: release flowtable after rcu grace period on errorCall synchronize_rcu() after unregistering the hooks from error path,since a hook that already refers to this flowtable can be alreadyregistered, exposing this flowtable to packet path and nfnetlink_hookcontrol plane.This error path is rare, it should only happen by reaching the maximumnumber hooks or by failing to set up to hardware offload, just callsynchronize_rcu().There is a check for already used device hooks by different flowtablethat could result in EEXIST at this late stage. The hook parser can beupdated to perform this check earlier to this error path really becomesrarely exercised.Uncovered by KASAN reported as use-after-free from nfnetlink_hook pathwhen dumping hooks.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bridge: cfm: Fix race condition in peer_mep deletionWhen a peer MEP is being deleted, cancel_delayed_work_sync() is calledon ccm_rx_dwork before freeing. However, br_cfm_frame_rx() runs insoftirq context under rcu_read_lock (without RTNL) and can re-scheduleccm_rx_dwork via ccm_rx_timer_start() between cancel_delayed_work_sync()returning and kfree_rcu() being called.The following is a simple race scenario: cpu0 cpu1mep_delete_implementation() cancel_delayed_work_sync(ccm_rx_dwork); br_cfm_frame_rx() // peer_mep still in hlist if (peer_mep->ccm_defect) ccm_rx_timer_start() queue_delayed_work(ccm_rx_dwork) hlist_del_rcu(&peer_mep->head); kfree_rcu(peer_mep, rcu); ccm_rx_work_expired() // on freed peer_mepTo prevent this, cancel_delayed_work_sync() is replaced withdisable_delayed_work_sync() in both peer MEP deletion paths, sothat subsequent queue_delayed_work() calls from br_cfm_frame_rx()are silently rejected.The cc_peer_disable() helper retains cancel_delayed_work_sync()because it is also used for the CC enable/disable toggle path wherethe work must remain re-schedulable.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1].smc_tcp_syn_recv_sock() is called in the TCP receive path(softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCPlistening socket). It reads sk_user_data to get the smc_sockpointer. However, when the SMC listen socket is being closedconcurrently, smc_close_active() sets clcsock->sk_user_datato NULL under sk_callback_lock, and then the smc_sock itselfcan be freed via sock_put() in smc_release().This leads to two issues:1) NULL pointer dereference: sk_user_data is NULL when accessed.2) Use-after-free: sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed.The race window looks like this (the syzkaller crash [1]triggers via the SYN cookie path: tcp_get_cookie_sock() ->smc_tcp_syn_recv_sock(), but the normal tcp_check_req() pathhas the same race): CPU A (softirq) CPU B (process ctx) tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) /* No lock on listener */ smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock freed! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL or dangling smc->queued_smc_hs -> crash!Note that the clcsock and smc_sock are two independent objectswith separate refcounts. TCP stack holds a reference on theclcsock, which keeps it alive, but this does NOT prevent thesmc_sock from being freed.Fix this by using RCU and refcount_inc_not_zero() to safelyaccess smc_sock. Since smc_tcp_syn_recv_sock() is called inthe TCP three-way handshake path, taking read_lock_bh onsk_callback_lock is too heavy and would not survive a SYNflood attack. Using rcu_read_lock() is much more lightweight.- Set SOCK_RCU_FREE on the SMC listen socket so that smc_sock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcu_read_lock().- Use rcu_read_lock() to protect reading sk_user_data.- Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely.Note: smc_hs_congested() has a similar lockless read ofsk_user_data without rcu_read_lock(), but it only checks forNULL and accesses the global smc_hs_wq, never dereferencingany smc_sock field, so it is not affected.Reproducer was verified with mdelay injection and smc_run,the issue no longer occurs with this patch applied.[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bonding: fix use-after-free in bond_xmit_broadcast()bond_xmit_broadcast() reuses the original skb for the last slave(determined by bond_is_last_slave()) and clones it for others.Concurrent slave enslave/release can mutate the slave list duringRCU-protected iteration, changing which slave is "last" mid-loop.This causes the original skb to be double-consumed (double-freed).Replace the racy bond_is_last_slave() check with a simple indexcomparison (i + 1 == slaves_count) against the pre-snapshot slavecount taken via READ_ONCE() before the loop. This preserves thezero-copy optimization for the last slave while making the "last"determination stable against concurrent list mutations.The UAF can trigger the following crash:==================================================================BUG: KASAN: slab-use-after-free in skb_cloneRead of size 8 at addr ffff888100ef8d40 by task exploit/147CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZYCall Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147:Freed by task 147:The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60)Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb>ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb==================================================================
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc()At the end of this function, d is the traversal cursor of flist, but thecode completes found instead. This can lead to issues such as NULL pointerdereferences, double completion, or descriptor leaks.Fix this by completing d instead of found in the finallist_for_each_entry_safe() loop.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutexMEDIA_REQUEST_IOC_REINIT can run concurrently with VIDIOC_REQBUFS(0)queue teardown paths. This can race request object cleanup against vb2queue cancellation and lead to use-after-free reports.We already serialize request queueing against STREAMON/OFF withreq_queue_mutex. Extend that serialization to REQBUFS, and also takethe same mutex in media_request_ioctl_reinit() so REINIT is in thesame exclusion domain.This keeps request cleanup and queue cancellation from running inparallel for request-capable devices.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iavf: fix out-of-bounds writes in iavf_get_ethtool_stats()iavf incorrectly uses real_num_tx_queues for ETH_SS_STATS. Since thevalue could change in runtime, we should use num_tx_queues instead.Moreover iavf_get_ethtool_stats() uses num_active_queues whileiavf_get_sset_count() and iavf_get_stat_strings() usereal_num_tx_queues, which triggers out-of-bounds writes when we do"ethtool -L" and "ethtool -S" simultaneously [1].For example when we change channels from 1 to 8, Thread 3 could bescheduled before Thread 2, and out-of-bounds writes could be triggeredin Thread 3:Thread 1 (ethtool -L) Thread 2 (work) Thread 3 (ethtool -S)iavf_set_channels()...iavf_alloc_queues()-> num_active_queues = 8iavf_schedule_finish_config() iavf_get_sset_count() real_num_tx_queues: 1 -> buffer for 1 queue iavf_get_ethtool_stats() num_active_queues: 8 -> out-of-bounds! iavf_finish_config() -> real_num_tx_queues = 8Use immutable num_tx_queues in all related functions to avoid the issue.[1] BUG: KASAN: vmalloc-out-of-bounds in iavf_add_one_ethtool_stat+0x200/0x270 Write of size 8 at addr ffffc900031c9080 by task ethtool/5800 CPU: 1 UID: 0 PID: 5800 Comm: ethtool Not tainted 6.19.0-enjuk-08403-g8137e3db7f1c #241 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x180 iavf_add_one_ethtool_stat+0x200/0x270 iavf_get_ethtool_stats+0x14c/0x2e0 __dev_ethtool+0x3d0c/0x5830 dev_ethtool+0x12d/0x270 dev_ioctl+0x53c/0xe30 sock_do_ioctl+0x1a9/0x270 sock_ioctl+0x3d4/0x5e0 __x64_sys_ioctl+0x137/0x1c0 do_syscall_64+0xf3/0x690 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7da0e6e36d ... The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900031c9000 allocated at __dev_ethtool+0x3cc9/0x5830 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88813a013de0 pfn:0x13a013 flags: 0x200000000000000(node=0|zone=2) raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff88813a013de0 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffc900031c8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900031c9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900031c9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/tls: fix use-after-free in -EBUSY error path of tls_do_encryptionThe -EBUSY handling in tls_do_encryption(), introduced by commit859054147318 ("net: tls: handle backlogging of crypto requests"), hasa use-after-free due to double cleanup of encrypt_pending and thescatterlist entry.When crypto_aead_encrypt() returns -EBUSY, the request is enqueued tothe cryptd backlog and the async callback tls_encrypt_done() will beinvoked upon completion. That callback unconditionally restores thescatterlist entry (sge->offset, sge->length) and decrementsctx->encrypt_pending. However, if tls_encrypt_async_wait() returns anerror, the synchronous error path in tls_do_encryption() performs thesame cleanup again, double-decrementing encrypt_pending anddouble-restoring the scatterlist.The double-decrement corrupts the encrypt_pending sentinel (initializedto 1), making tls_encrypt_async_wait() permanently skip the wait forpending async callbacks. A subsequent sendmsg can then free thetls_rec via bpf_exec_tx_verdict() while a cryptd callback is stillpending, resulting in a use-after-free when the callback fires on thefreed record.Fix this by skipping the synchronous cleanup when the -EBUSY asyncwait returns an error, since the callback has already handledencrypt_pending and sge restoration.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:futex: Clear stale exiting pointer in futex_lock_pi() retry pathFuzzying/stressing futexes triggered: WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSYand stores a refcounted task pointer in 'exiting'.After wait_for_owner_exiting() consumes that reference, the local pointeris never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns adifferent error, the bogus pointer is passed to wait_for_owner_exiting(). CPU0 CPU1 CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit() futex_cleanup_begin() futex_state = EXITING; futex_lock_pi(uaddr) futex_lock_pi_atomic() attach_to_pi_owner() // observes EXITING *exiting = owner; // takes ref return -EBUSY wait_for_owner_exiting(-EBUSY, owner) put_task_struct(); // drops ref // exiting still points to owner goto retry; futex_lock_pi_atomic() lock_pi_update_atomic() cmpxchg(uaddr) *uaddr ^= WAITERS // whatever // value changed return -EAGAIN; wait_for_owner_exiting(-EAGAIN, exiting) // stale WARN_ON_ONCE(exiting)Fix this by resetting upon retry, essentially aligning it with requeue_pi.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gw: fix OOB heap access in cgw_csum_crc8_rel()cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx(): int from = calc_idx(crc8->from_idx, cf->len); int to = calc_idx(crc8->to_idx, cf->len); int res = calc_idx(crc8->result_idx, cf->len); if (from < 0 || to < 0 || res < 0) return;However, the loop and the result write then use the raw s8 fields directlyinstead of the computed variables: for (i = crc8->from_idx; ...) /* BUG: raw negative index */ cf->data[crc8->result_idx] = ...; /* BUG: raw negative index */With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame,calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates withi = -64, reading cf->data[-64], and the write goes to cf->data[-64].This write might end up to 56 (7.0-rc) or 40 (<= 6.19) bytes before thestart of the canfd_frame on the heap.The companion function cgw_csum_xor_rel() uses `from`/`to`/`res`correctly throughout; fix cgw_csum_crc8_rel() to match.Confirmed with KASAN on linux-7.0-rc2: BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0 Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeatA use-after-free / refcount underflow is possible when the heartbeatworker and intel_engine_park_heartbeat() race to release the sameengine->heartbeat.systole request.The heartbeat worker reads engine->heartbeat.systole and callsi915_request_put() on it when the request is complete, but clearsthe pointer in a separate, non-atomic step. Concurrently, a requestretirement on another CPU can drop the engine wakeref to zero, triggering__engine_park() -> intel_engine_park_heartbeat(). If the heartbeattimer is pending at that point, cancel_delayed_work() returns true andintel_engine_park_heartbeat() reads the stale non-NULL systole pointerand calls i915_request_put() on it again, causing a refcount underflow:```<4> [487.221889] Workqueue: i915-unordered engine_retire [i915]<4> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0...<4> [487.222707] Call Trace:<4> [487.222711] <4> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915]<4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915]<4> [487.223566] __engine_park+0xb9/0x650 [i915]<4> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915]<4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915]<4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915]<4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915]<4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915]<4> [487.226178] i915_request_retire+0x1c/0x40 [i915]<4> [487.226625] engine_retire+0x122/0x180 [i915]<4> [487.227037] process_one_work+0x239/0x760<4> [487.227060] worker_thread+0x200/0x3f0<4> [487.227068] ? __pfx_worker_thread+0x10/0x10<4> [487.227075] kthread+0x10d/0x150<4> [487.227083] ? __pfx_kthread+0x10/0x10<4> [487.227092] ret_from_fork+0x3d4/0x480<4> [487.227099] ? __pfx_kthread+0x10/0x10<4> [487.227107] ret_from_fork_asm+0x1a/0x30<4> [487.227141] ```Fix this by replacing the non-atomic pointer read + separate clear withxchg() in both racing paths. xchg() is a single indivisible hardwareinstruction that atomically reads the old pointer and writes NULL. Thisguarantees only one of the two concurrent callers obtains the non-NULLpointer and performs the put, the other gets NULL and skips it.(cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix slab-use-after-free in __inet_lookup_establishedThe ehash table lookups are lockless and rely onSLAB_TYPESAFE_BY_RCU to guarantee socket memory stabilityduring RCU read-side critical sections. Both tcp_prot andtcpv6_prot have their slab caches created with this flagvia proto_register().However, MPTCP's mptcp_subflow_init() copies tcpv6_prot intotcpv6_prot_override during inet_init() (fs_initcall, level 5),before inet6_init() (module_init/device_initcall, level 6) hascalled proto_register(&tcpv6_prot). At that point,tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slabremains NULL permanently.This causes MPTCP v6 subflow child sockets to be allocated viakmalloc (falling into kmalloc-4k) instead of the TCPv6 slabcache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, sowhen these sockets are freed without SOCK_RCU_FREE (which iscleared for child sockets by design), the memory can beimmediately reused. Concurrent ehash lookups underrcu_read_lock can then access freed memory, triggering aslab-use-after-free in __inet_lookup_established.Fix this by splitting the IPv6-specific initialization out ofmptcp_subflow_init() into a new mptcp_subflow_v6_init(), calledfrom mptcp_proto_v6_init() before protocol registration. Thisensures tcpv6_prot_override.slab correctly inherits theSLAB_TYPESAFE_BY_RCU slab cache.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: ccp: Don't attempt to copy ID to userspace if PSP command failedWhen retrieving the ID for the CPU, don't attempt to copy the ID blob touserspace if the firmware command failed. If the failure was due to aninvalid length, i.e. the userspace buffer+length was too small, copyingthe number of bytes _firmware_ requires will overflow the kernel-allocatedbuffer and leak 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 64 at addr ffff8881867f5960 by task syz.0.906/24388 CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 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_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222 sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575 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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: jq is a command-line JSON processor. In 1.8.1 and earlier, the jq bytecode VM's data stack tracks its allocation size in a signed int. When the stack grows beyond ~1 GiB (via deeply nested generator forks), the doubling arithmetic overflows. The wrapped value is passed to realloc and then used for a memmove with attacker-influenced offsets.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_helper: pass helper to expect cleanupnf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy()to remove expectations belonging to the helper being unregistered.However, it passes NULL instead of the helper pointer as the dataargument, so expect_iter_me() never matches any expectation and allof them survive the cleanup.After unregister returns, nfnl_cthelper_del() frees the helperobject immediately. Subsequent expectation dumps or packet-driveninit_conntrack() calls then dereference the freed exp->helper,causing a use-after-free.Pass the actual helper pointer so expectations referencing it areproperly destroyed before the helper object is freed. BUG: KASAN: slab-use-after-free in string+0x38f/0x430 Read of size 1 at addr ffff888003b14d20 by task poc/103 Call Trace: string+0x38f/0x430 vsnprintf+0x3cc/0x1170 seq_printf+0x17a/0x240 exp_seq_show+0x2e5/0x560 seq_read_iter+0x419/0x1280 proc_reg_read+0x1ac/0x270 vfs_read+0x179/0x930 ksys_read+0xef/0x1c0 Freed by task 103: The buggy address is located 32 bytes inside of freed 192-byte region [ffff888003b14d00, ffff888003b14dc0)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: remove xfs_attr_leaf_hasnameThe calling convention of xfs_attr_leaf_hasname() is problematic, becauseit returns a NULL buffer when xfs_attr3_leaf_read fails, a valid bufferwhen xfs_attr3_leaf_lookup_int returns -ENOATTR or -EEXIST, and anon-NULL buffer pointer for an already released buffer whenxfs_attr3_leaf_lookup_int fails with other error values.Fix this by simply open coding xfs_attr_leaf_hasname in the callers, sothat the buffer release code is done by each caller ofxfs_attr3_leaf_read.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Add SRCU protection for reading PDPTRs in __get_sregs2()Add SRCU read-side protection when reading PDPTR registers in__get_sregs2().Reading PDPTRs may trigger access to guest memory:kvm_pdptr_read() -> svm_cache_reg() -> load_pdptrs() ->kvm_vcpu_read_guest_page() -> kvm_vcpu_gfn_to_memslot()kvm_vcpu_gfn_to_memslot() dereferences memslots via __kvm_memslots(),which uses srcu_dereference_check() and requires either kvm->srcu orkvm->slots_lock to be held. Currently only vcpu->mutex is held,triggering lockdep warning:=============================WARNING: suspicious RCU usage in kvm_vcpu_gfn_to_memslot6.12.59+ #3 Not taintedinclude/linux/kvm_host.h:1062 suspicious rcu_dereference_check() usage!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 11 lock held by syz.5.1717/15100: #0: ff1100002f4b00b0 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x1d5/0x1590Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xf0/0x120 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x1e3/0x270 kernel/locking/lockdep.c:6824 __kvm_memslots include/linux/kvm_host.h:1062 [inline] __kvm_memslots include/linux/kvm_host.h:1059 [inline] kvm_vcpu_memslots include/linux/kvm_host.h:1076 [inline] kvm_vcpu_gfn_to_memslot+0x518/0x5e0 virt/kvm/kvm_main.c:2617 kvm_vcpu_read_guest_page+0x27/0x50 virt/kvm/kvm_main.c:3302 load_pdptrs+0xff/0x4b0 arch/x86/kvm/x86.c:1065 svm_cache_reg+0x1c9/0x230 arch/x86/kvm/svm/svm.c:1688 kvm_pdptr_read arch/x86/kvm/kvm_cache_regs.h:141 [inline] __get_sregs2 arch/x86/kvm/x86.c:11784 [inline] kvm_arch_vcpu_ioctl+0x3e20/0x4aa0 arch/x86/kvm/x86.c:6279 kvm_vcpu_ioctl+0x856/0x1590 virt/kvm/kvm_main.c:4663 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xbd/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fFound by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/kbuf: check if target buffer list is still legacy on recycleThere's a gap between when the buffer was grabbed and when itpotentially gets recycled, where if the list is empty, someone could'veupgraded it to a ring provided type. This can happen if the requestis forced via io-wq. The legacy recycling is missing checking if thebuffer_list still exists, and if it's of the correct type. Add thosechecks.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- sed > 0-0 (version in image is 4.4-150300.13.6.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: storage: sddr55: Reject out-of-bound new_pbaDiscovered by Atuin - Automated Vulnerability Discovery Engine.new_pba comes from the status packet returned after each write.A bogus device could report values beyond the block count derivedfrom info->capacity, letting the driver walk off the end ofpba_to_lba[] and corrupt heap memory.Reject PBAs that exceed the computed block count and fail thetransfer so we avoid touching out-of-range mapping entries.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: jq is a command-line JSON processor. An integer overflow vulnerability exists through version 1.8.1 within the jvp_string_append() and jvp_string_copy_replace_bad functions, where concatenating strings with a combined length exceeding 2^31 bytes causes a 32-bit unsigned integer overflow in the buffer allocation size calculation, resulting in a drastically undersized heap buffer. Subsequent memory copy operations then write the full string data into this undersized buffer, causing a heap buffer overflow classified as CWE-190 (Integer Overflow) leading to CWE-122 (Heap-based Buffer Overflow). Any system evaluating untrusted jq queries is affected, as an attacker can crash the process or potentially achieve further exploitation through heap corruption by crafting queries that produce extremely large strings. The root cause is the absence of string size bounds checking, unlike arrays and objects which already have size limits. The issue has been addressed in commit e47e56d226519635768e6aab2f38f0ab037c09e5.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZEROPrecision markers need to be propagated whenever we have an ARG_CONST_*style argument, as the verifier cannot consider imprecise scalars to beequivalent for the purposes of states_equal check when such argumentsrefine the return value (in this case, set mem_size for PTR_TO_MEM). Theresultant mem_size for the R0 is derived from the constant value, and ifthe verifier incorrectly prunes states considering them equivalent wheresuch arguments exist (by seeing that both registers have reg->precise asfalse in regsafe), we can end up with invalid programs passing theverifier which can do access beyond what should have been the correctmem_size in that explored state.To show a concrete example of the problem:0000000000000000
: 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: if r3 > r2 goto +18 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32 *)(r1 + 0) 8: r2 = 1 9: if w1 == 0 goto +1 10: r2 = -10000000000000058 : 11: r1 = 0 ll 13: r3 = 0 14: call bpf_ringbuf_reserve 15: if r0 == 0 goto +7 16: r1 = r0 17: r1 += 16777215 18: w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: call bpf_ringbuf_submit00000000000000b8 : 23: w0 = 0 24: exitFor the first case, the single line execution's exploration will prunethe search at insn 14 for the branch insn 9's second leg as it will beverified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 willalways be 0 so at runtime we don't get error for being greater thanUINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe justsees reg->precise as false for both r2 registers in both states, henceconsiders them equal for purposes of states_equal.If we propagated precise markers using the backtracking support, wewould use the precise marking to then ensure that old r2 (UINT_MAX) waswithin the new r2 (1) and this would never be true, so the verificationwould rightfully fail.The end result is that the out of bounds access at instruction 19 wouldbe permitted without this fix.Note that reg->precise is always set to true when user does not haveCAP_BPF (or when subprog count is greater than 1 (i.e. use of any staticor global functions)), hence this is only a problem when precision marksneed to be explicitly propagated (i.e. privileged users with CAP_BPF).A simplified test case has been included in the next patch to preventfuture regressions.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: validate the extent length for uncompressed pclusterssyzkaller reported a KASAN use-after-free:https://syzkaller.appspot.com/bug?extid=2ae90e873e97f1faf6f2The referenced fuzzed image actually has two issues: - m_pa == 0 as a non-inlined pcluster; - The logical length is longer than its physical length.The first issue has already been addressed. This patch addressesthe second issue by checking the extent length validity.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:lwt: Fix return values of BPF xmit opsBPF encap ops can return different types of positive values, such likeNET_RX_DROP, NET_XMIT_CN, NETDEV_TX_BUSY, and so on, from functionskb_do_redirect and bpf_lwt_xmit_reroute. At the xmit hook, such returnvalues would be treated implicitly as LWTUNNEL_XMIT_CONTINUE inip(6)_finish_output2. When this happens, skbs that have been freed wouldcontinue to the neighbor subsystem, causing use-after-free bug andkernel crashes.To fix the incorrect behavior, skb_do_redirect return values can besimply discarded, the same as tc-egress behavior. On the other hand,bpf_lwt_xmit_reroute returns useful errors to local senders, e.g. PMTUinformation. Thus convert its return values to avoid the conflict withLWTUNNEL_XMIT_CONTINUE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: do not free live elementPablo reports a crash with large batches of elements with aback-to-back add/remove pattern. Quoting Pablo: add_elem("00000000") timeout 100 ms ... add_elem("0000000X") timeout 100 ms del_elem("0000000X") <---------------- delete one that was just added ... add_elem("00005000") timeout 100 ms 1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat.Looking at the remove function there is a chance that we will drop arule that maps to a non-deactivated element.Removal happens in two steps, first we do a lookup for key k and return theto-be-removed element and mark it as inactive in the next generation.Then, in a second step, the element gets removed from the set/map.The _remove function does not work correctly if we have more than oneelement that share the same key.This can happen if we insert an element into a set when the set alreadyholds an element with same key, but the element mapping to the existingkey has timed out or is not active in the next generation.In such case its possible that removal will unmap the wrong element.If this happens, we will leak the non-deactivated element, it becomesunreachable.The element that got deactivated (and will be freed later) willremain reachable in the set data structure, this can result ina crash when such an element is retrieved during lookup (stalepointer).Add a check that the fully matching key does in fact map to the elementthat we have marked as inactive in the deactivation step.If not, we need to continue searching.Add a bug/warn trap at the end of the function as well, the removefunction must not ever be called with an invisible/unreachable/non-existentelement.v2: avoid uneeded temporary variable (Stefano)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: A flaw was found in grub2. A specially crafted JPEG file can cause the JPEG parser of grub2 to incorrectly check the bounds of its internal buffers, resulting in an out-of-bounds write. The possibility of overwriting sensitive information to bypass secure boot protections is not discarded.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.65.1).
-
Description: A flaw was found in grub2. When reading a symbolic link's name from a UFS filesystem, grub2 fails to validate the string length taken as an input. The lack of validation may lead to a heap out-of-bounds write, causing data integrity issues and eventually allowing an attacker to circumvent secure boot protections.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.65.1).
-
Description: A flaw was found in the HFS filesystem. When reading an HFS volume's name at grub_fs_mount(), the HFS filesystem driver performs a strcpy() using the user-provided volume name as input without properly validating the volume name's length. This issue may read to a heap-based out-of-bounds writer, impacting grub's sensitive data integrity and eventually leading to a secure boot protection bypass.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.65.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix overloading of MEM_UNINIT's meaningLonial reported an issue in the BPF verifier where check_mem_size_reg()has the following code: if (!tnum_is_const(reg->var_off)) /* For unprivileged variable accesses, disable raw * mode so that the program is required to * initialize all the memory that the helper could * just partially fill up. */ meta = NULL;This means that writes are not checked when the register containing thesize of the passed buffer has not a fixed size. Through this bug, a BPFprogram can write to a map which is marked as read-only, for example,.rodata global maps.The problem is that MEM_UNINIT's initial meaning that "the passed bufferto the BPF helper does not need to be initialized" which was added backin commit 435faee1aae9 ("bpf, verifier: add ARG_PTR_TO_RAW_STACK type")got overloaded over time with "the passed buffer is being written to".The problem however is that checks such as the above which were added latervia 06c1c049721a ("bpf: allow helpers access to variable memory") set metato NULL in order force the user to always initialize the passed buffer tothe helper. Due to the current double meaning of MEM_UNINIT, this bypassesverifier write checks to the memory (not boundary checks though) and onlyassumes the latter memory is read instead.Fix this by reverting MEM_UNINIT back to its original meaning, and havingMEM_WRITE as an annotation to BPF helpers in order to then trigger theBPF verifier checks for writing to memory.Some notes: check_arg_pair_ok() ensures that for ARG_CONST_SIZE{,_OR_ZERO}we can access fn->arg_type[arg - 1] since it must contain a precedingARG_PTR_TO_MEM. For check_mem_reg() the meta argument can be removedaltogether since we do check both BPF_READ and BPF_WRITE. Same for theequivalent check_kfunc_mem_size_reg().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix usage slab after free[ +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147[ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1[ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020[ +0.000016] Call Trace:[ +0.000008] [ +0.000009] dump_stack_lvl+0x76/0xa0[ +0.000017] print_report+0xce/0x5f0[ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000019] ? srso_return_thunk+0x5/0x5f[ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200[ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000019] kasan_report+0xbe/0x110[ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000023] __asan_report_load8_noabort+0x14/0x30[ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000020] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? __kasan_check_write+0x14/0x30[ +0.000016] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched][ +0.000020] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? __kasan_check_write+0x14/0x30[ +0.000013] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? enable_work+0x124/0x220[ +0.000015] ? __pfx_enable_work+0x10/0x10[ +0.000013] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? free_large_kmalloc+0x85/0xf0[ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched][ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu][ +0.000735] ? __kasan_check_read+0x11/0x20[ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu][ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu][ +0.000679] ? mutex_unlock+0x80/0xe0[ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu][ +0.000662] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? __kasan_check_write+0x14/0x30[ +0.000013] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? mutex_unlock+0x80/0xe0[ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu][ +0.000663] drm_minor_release+0xc9/0x140 [drm][ +0.000081] drm_release+0x1fd/0x390 [drm][ +0.000082] __fput+0x36c/0xad0[ +0.000018] __fput_sync+0x3c/0x50[ +0.000014] __x64_sys_close+0x7d/0xe0[ +0.000014] x64_sys_call+0x1bc6/0x2680[ +0.000014] do_syscall_64+0x70/0x130[ +0.000014] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190[ +0.000015] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? irqentry_exit+0x43/0x50[ +0.000012] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? exc_page_fault+0x7c/0x110[ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ +0.000014] RIP: 0033:0x7ffff7b14f67[ +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff[ +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003[ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67[ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003[ +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000[ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8[ +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040[ +0.000020] [ +0.000016] Allocated by task 383 on cpu 7 at 26.880319s:[ +0.000014] kasan_save_stack+0x28/0x60[ +0.000008] kasan_save_track+0x18/0x70[ +0.000007] kasan_save_alloc_info+0x38/0x60[ +0.000007] __kasan_kmalloc+0xc1/0xd0[ +0.000007] kmalloc_trace_noprof+0x180/0x380[ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched][ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu][ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu][ +0.000662] amdgpu_pci_p---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/igen6: Avoid segmentation fault on module unloadThe segmentation fault happens because:During modprobe:1. In igen6_probe(), igen6_pvt will be allocated with kzalloc()2. In igen6_register_mci(), mci->pvt_info will point to &igen6_pvt->imc[mc]During rmmod:1. In mci_release() in edac_mc.c, it will kfree(mci->pvt_info)2. In igen6_remove(), it will kfree(igen6_pvt);Fix this issue by setting mci->pvt_info to NULL to avoid the doublekfree.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries/vas: Add close() callback in vas_vm_ops structThe mapping VMA address is saved in VAS window struct when thepaste address is mapped. This VMA address is used during migrationto unmap the paste address if the window is active. The pasteaddress mapping will be removed when the window is closed or withthe munmap(). But the VMA address in the VAS window is not updatedwith munmap() which is causing invalid access during migration.The KASAN report shows:[16386.254991] BUG: KASAN: slab-use-after-free in reconfig_close_windows+0x1a0/0x4e8[16386.255043] Read of size 8 at addr c00000014a819670 by task drmgr/696928[16386.255096] CPU: 29 UID: 0 PID: 696928 Comm: drmgr Kdump: loaded Tainted: G B 6.11.0-rc5-nxgzip #2[16386.255128] Tainted: [B]=BAD_PAGE[16386.255148] Hardware name: IBM,9080-HEX Power11 (architected) 0x820200 0xf000007 of:IBM,FW1110.00 (NH1110_016) hv:phyp pSeries[16386.255181] Call Trace:[16386.255202] [c00000016b297660] [c0000000018ad0ac] dump_stack_lvl+0x84/0xe8 (unreliable)[16386.255246] [c00000016b297690] [c0000000006e8a90] print_report+0x19c/0x764[16386.255285] [c00000016b297760] [c0000000006e9490] kasan_report+0x128/0x1f8[16386.255309] [c00000016b297880] [c0000000006eb5c8] __asan_load8+0xac/0xe0[16386.255326] [c00000016b2978a0] [c00000000013f898] reconfig_close_windows+0x1a0/0x4e8[16386.255343] [c00000016b297990] [c000000000140e58] vas_migration_handler+0x3a4/0x3fc[16386.255368] [c00000016b297a90] [c000000000128848] pseries_migrate_partition+0x4c/0x4c4...[16386.256136] Allocated by task 696554 on cpu 31 at 16377.277618s:[16386.256149] kasan_save_stack+0x34/0x68[16386.256163] kasan_save_track+0x34/0x80[16386.256175] kasan_save_alloc_info+0x58/0x74[16386.256196] __kasan_slab_alloc+0xb8/0xdc[16386.256209] kmem_cache_alloc_noprof+0x200/0x3d0[16386.256225] vm_area_alloc+0x44/0x150[16386.256245] mmap_region+0x214/0x10c4[16386.256265] do_mmap+0x5fc/0x750[16386.256277] vm_mmap_pgoff+0x14c/0x24c[16386.256292] ksys_mmap_pgoff+0x20c/0x348[16386.256303] sys_mmap+0xd0/0x160...[16386.256350] Freed by task 0 on cpu 31 at 16386.204848s:[16386.256363] kasan_save_stack+0x34/0x68[16386.256374] kasan_save_track+0x34/0x80[16386.256384] kasan_save_free_info+0x64/0x10c[16386.256396] __kasan_slab_free+0x120/0x204[16386.256415] kmem_cache_free+0x128/0x450[16386.256428] vm_area_free_rcu_cb+0xa8/0xd8[16386.256441] rcu_do_batch+0x2c8/0xcf0[16386.256458] rcu_core+0x378/0x3c4[16386.256473] handle_softirqs+0x20c/0x60c[16386.256495] do_softirq_own_stack+0x6c/0x88[16386.256509] do_softirq_own_stack+0x58/0x88[16386.256521] __irq_exit_rcu+0x1a4/0x20c[16386.256533] irq_exit+0x20/0x38[16386.256544] interrupt_async_exit_prepare.constprop.0+0x18/0x2c...[16386.256717] Last potentially related work creation:[16386.256729] kasan_save_stack+0x34/0x68[16386.256741] __kasan_record_aux_stack+0xcc/0x12c[16386.256753] __call_rcu_common.constprop.0+0x94/0xd04[16386.256766] vm_area_free+0x28/0x3c[16386.256778] remove_vma+0xf4/0x114[16386.256797] do_vmi_align_munmap.constprop.0+0x684/0x870[16386.256811] __vm_munmap+0xe0/0x1f8[16386.256821] sys_munmap+0x54/0x6c[16386.256830] system_call_exception+0x1a0/0x4a0[16386.256841] system_call_vectored_common+0x15c/0x2ec[16386.256868] The buggy address belongs to the object at c00000014a819670 which belongs to the cache vm_area_struct of size 168[16386.256887] The buggy address is located 0 bytes inside of freed 168-byte region [c00000014a819670, c00000014a819718)[16386.256915] The buggy address belongs to the physical page:[16386.256928] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14a81[16386.256950] memcg:c0000000ba430001[16386.256961] anon flags: 0x43ffff800000000(node=4|zone=0|lastcpupid=0x7ffff)[16386.256975] page_type: 0xfdffffff(slab)[16386---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Remove the direct link to net_deviceThe similar patch in siw is in the link:https://git.kernel.org/rdma/rdma/c/16b87037b48889This problem also occurred in RXE. The following analyze this problem.In the following Call Traces:"BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0 net/core/dev.c:8782Read of size 4 at addr ffff8880554640b0 by task kworker/1:4/5295CPU: 1 UID: 0 PID: 5295 Comm: kworker/1:4 Not tainted6.12.0-rc3-syzkaller-00399-g9197b73fd7bb #0Hardware name: Google Compute Engine/Google Compute Engine,BIOS Google 09/13/2024Workqueue: infiniband ib_cache_event_taskCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 dev_get_flags+0x188/0x1d0 net/core/dev.c:8782 rxe_query_port+0x12d/0x260 drivers/infiniband/sw/rxe/rxe_verbs.c:60 __ib_query_port drivers/infiniband/core/device.c:2111 [inline] ib_query_port+0x168/0x7d0 drivers/infiniband/core/device.c:2143 ib_cache_update+0x1a9/0xb80 drivers/infiniband/core/cache.c:1494 ib_cache_event_task+0xf3/0x1e0 drivers/infiniband/core/cache.c:1568 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f2/0x390 kernel/kthread.c:389 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 "1). In the link [1]," infiniband syz2: set down"This means that on 839.350575, the event ib_cache_event_task was sent andiqueued in ib_wq.2). In the link [1]," team0 (unregistering): Port device team_slave_0 removed"It indicates that before 843.251853, the net device should be freed.3). In the link [1]," BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0"This means that on 850.559070, this slab-use-after-free problem occurred.In all, on 839.350575, the event ib_cache_event_task was sent and queuedin ib_wq,before 843.251853, the net device veth was freed.on 850.559070, this event was executed, and the mentioned freed net devicewas called. Thus, the above call trace occurred.[1] https://syzkaller.appspot.com/x/log.txt?x=12e7025f980000
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/siw: Remove direct link to net_deviceDo not manage a per device direct link to net_device. Relyon associated ib_devices net_device management, not doublingthe effort locally. A badly managed local link to net_devicewas causing a 'KASAN: slab-use-after-free' exception duringsiw_query_port() call.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm array: fix releasing a faulty array block twice in dm_array_cursor_endWhen dm_bm_read_lock() fails due to locking or checksum errors, itreleases the faulty block implicitly while leaving an invalid outputpointer behind. The caller of dm_bm_read_lock() should not operate onthis invalid dm_block pointer, or it will lead to undefined result.For example, the dm_array_cursor incorrectly caches the invalid pointeron reading a faulty array block, causing a double release indm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put().Reproduce steps:1. initialize a cache devicedmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc $262144"dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"2. wipe the second array block offlinedmsteup remove cache cmeta cdata corigmapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \2>/dev/null | hexdump -e '1/8 "%u\n"')ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \2>/dev/null | hexdump -e '1/8 "%u\n"')dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock3. try reopen the cache devicedmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc $262144"dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"Kernel logs:(snip)device-mapper: array: array_block_check failed: blocknr 0 != wanted 10device-mapper: block manager: array validator check failed for block 10device-mapper: array: get_ablock faileddevice-mapper: cache metadata: dm_array_cursor_next for mapping failed------------[ cut here ]------------kernel BUG at drivers/md/dm-bufio.c:638!Fix by setting the cached block pointer to NULL on errors.In addition to the reproducer described above, this fix can beverified using the "array_cursor/damaged" test in dm-unit: dm-unit run /pdata/array_cursor/damaged --kernel-dir
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Fix use-after free in init error and remove pathsdevm_blk_crypto_profile_init() registers a cleanup handler to run whenthe associated (platform-) device is being released. For UFS, thecrypto private data and pointers are stored as part of the ufs_hba'sdata structure 'struct ufs_hba::crypto_profile'. This structure isallocated as part of the underlying ufshcd and therefore Scsi_hostallocation.During driver release or during error handling in ufshcd_pltfrm_init(),this structure is released as part of ufshcd_dealloc_host() before the(platform-) device associated with the crypto call above is released.Once this device is released, the crypto cleanup code will run, usingthe just-released 'struct ufs_hba::crypto_profile'. This causes ause-after-free situation: Call trace: kfree+0x60/0x2d8 (P) kvfree+0x44/0x60 blk_crypto_profile_destroy_callback+0x28/0x70 devm_action_release+0x1c/0x30 release_nodes+0x6c/0x108 devres_release_all+0x98/0x100 device_unbind_cleanup+0x20/0x70 really_probe+0x218/0x2d0In other words, the initialisation code flow is: platform-device probe ufshcd_pltfrm_init() ufshcd_alloc_host() scsi_host_alloc() allocation of struct ufs_hba creation of scsi-host devices devm_blk_crypto_profile_init() devm registration of cleanup handler using platform-deviceand during error handling of ufshcd_pltfrm_init() or during driverremoval: ufshcd_dealloc_host() scsi_host_put() put_device(scsi-host) release of struct ufs_hba put_device(platform-device) crypto cleanup handlerTo fix this use-after free, change ufshcd_alloc_host() to register adevres action to automatically cleanup the underlying SCSI device onufshcd destruction, without requiring explicit calls toufshcd_dealloc_host(). This way: * the crypto profile and all other ufs_hba-owned resources are destroyed before SCSI (as they've been registered after) * a memleak is plugged in tc-dwc-g210-pci.c remove() as a side-effect * EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as it's not needed anymore * no future drivers using ufshcd_alloc_host() could ever forget adding the cleanup
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: pktgen: fix access outside of user given buffer in pktgen_thread_write()Honour the user given buffer size for the strn_len() calls (otherwisestrn_len() will access memory outside of the user given buffer).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix UAF when lookup kallsym after ftrace disabledThe following issue happens with a buggy module:BUG: unable to handle page fault for address: ffffffffc05d0218PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0Oops: Oops: 0000 [#1] SMP KASAN PTITainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULEHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSRIP: 0010:sized_strscpy+0x81/0x2f0RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffffffc0601010 RCX: dffffc0000000000RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2dRBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68R10: ffff88812608d82d R11: ffff88812608d810 R12: 0000000000000038R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeffFS: 00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ftrace_mod_get_kallsym+0x1ac/0x590 update_iter_mod+0x239/0x5b0 s_next+0x5b/0xa0 seq_read_iter+0x8c9/0x1070 seq_read+0x249/0x3b0 proc_reg_read+0x1b0/0x280 vfs_read+0x17f/0x920 ksys_read+0xf3/0x1c0 do_syscall_64+0x5f/0x2e0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe above issue may happen as follows:(1) Add kprobe tracepoint;(2) insmod test.ko;(3) Module triggers ftrace disabled;(4) rmmod test.ko;(5) cat /proc/kallsyms; --> Will trigger UAF as test.ko already removed;ftrace_mod_get_kallsym()...strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN);...The problem is when a module triggers an issue with ftrace andsets ftrace_disable. The ftrace_disable is set when an anomaly isdiscovered and to prevent any more damage, ftrace stops all textmodification. The issue that happened was that the ftrace_disable stopsmore than just the text modification.When a module is loaded, its init functions can also be traced. Becausekallsyms deletes the init functions after a module has loaded, ftracesaves them when the module is loaded and function tracing is enabled. Thisallows the output of the function trace to show the init function namesinstead of just their raw memory addresses.When a module is removed, ftrace_release_mod() is called, and ifftrace_disable is set, it just returns without doing anything more. Theproblem here is that it leaves the mod_list still around and if kallsymsis called, it will call into this code and access the module memory thathas already been freed as it will return: strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN);Where the "mod" no longer exists and triggers a UAF bug.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm-stripe: fix a possible integer overflowThere's a possible integer overflow in stripe_io_hints if we have toolarge chunk size. Test if the overflow happened, and if it did, don't setlimits->io_min and limits->io_opt;
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_router: Fix neighbour use-after-freeWe sometimes observe use-after-free when dereferencing a neighbour [1].The problem seems to be that the driver stores a pointer to theneighbour, but without holding a reference on it. A reference is onlytaken when the neighbour is used by a nexthop.Fix by simplifying the reference counting scheme. Always take areference when storing a neighbour pointer in a neighbour entry. Avoidtaking a referencing when the neighbour is used by a nexthop as theneighbour entry associated with the nexthop already holds a reference.Tested by running the test that uncovered the problem over 300 times.Without this patch the problem was reproduced after a handful ofiterations.[1]BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310Read of size 8 at addr ffff88817f8e3420 by task ip/3929CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full)Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023Call Trace: dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6e/0x300 print_report+0xfc/0x1fb kasan_report+0xe4/0x110 mlxsw_sp_neigh_entry_update+0x2d4/0x310 mlxsw_sp_router_rif_gone_sync+0x35f/0x510 mlxsw_sp_rif_destroy+0x1ea/0x730 mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0 __mlxsw_sp_inetaddr_lag_event+0xcc/0x130 __mlxsw_sp_inetaddr_event+0xf5/0x3c0 mlxsw_sp_router_netdevice_event+0x1015/0x1580 notifier_call_chain+0xcc/0x150 call_netdevice_notifiers_info+0x7e/0x100 __netdev_upper_dev_unlink+0x10b/0x210 netdev_upper_dev_unlink+0x79/0xa0 vrf_del_slave+0x18/0x50 do_set_master+0x146/0x7d0 do_setlink.isra.0+0x9a0/0x2880 rtnl_newlink+0x637/0xb20 rtnetlink_rcv_msg+0x6fe/0xb90 netlink_rcv_skb+0x123/0x380 netlink_unicast+0x4a3/0x770 netlink_sendmsg+0x75b/0xc90 __sock_sendmsg+0xbe/0x160 ____sys_sendmsg+0x5b2/0x7d0 ___sys_sendmsg+0xfd/0x180 __sys_sendmsg+0x124/0x1c0 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53[...]Allocated by task 109: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x2c1/0x790 neigh_alloc+0x6af/0x8f0 ___neigh_create+0x63/0xe90 mlxsw_sp_nexthop_neigh_init+0x430/0x7e0 mlxsw_sp_nexthop_type_init+0x212/0x960 mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280 mlxsw_sp_nexthop6_group_get+0x392/0x6a0 mlxsw_sp_fib6_entry_create+0x46a/0xfd0 mlxsw_sp_router_fib6_replace+0x1ed/0x5f0 mlxsw_sp_router_fib6_event_work+0x10a/0x2a0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20Freed by task 154: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kmem_cache_free_bulk.part.0+0x1eb/0x5e0 kvfree_rcu_bulk+0x1f2/0x260 kfree_rcu_work+0x130/0x1b0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20Last potentially related work creation: kasan_save_stack+0x30/0x50 kasan_record_aux_stack+0x8c/0xa0 kvfree_call_rcu+0x93/0x5b0 mlxsw_sp_router_neigh_event_work+0x67d/0x860 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:openvswitch: validate MPLS set/set_masked payload lengthvalidate_set() accepted OVS_KEY_ATTR_MPLS as variable-sized payload forSET/SET_MASKED actions. In action handling, OVS expects fixed-sizeMPLS key data (struct ovs_key_mpls).Use the already normalized key_len (masked case included) and rejectnon-matching MPLS action key sizes.Reject invalid MPLS action payload lengths early.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/kasan: fix double free for kasan pXdskasan_free_pxd() assumes the page table is always struct page aligned. But that's not always the case for all architectures. E.g. In case ofpowerpc with 64K pagesize, PUD table (of size 4096) comes from slab cachenamed pgtable-2^9. Hence instead of page_to_virt(pxd_page()) let's justdirectly pass the start of the pxd table which is passed as the 1stargument.This fixes the below double free kasan issue seen with PMEM:radix-mmu: Mapped 0x0000047d10000000-0x0000047f90000000 with 2.00 MiB pages==================================================================BUG: KASAN: double-free in kasan_remove_zero_shadow+0x9c4/0xa20Free of addr c0000003c38e0000 by task ndctl/2164CPU: 34 UID: 0 PID: 2164 Comm: ndctl Not tainted 6.19.0-rc1-00048-gea1013c15392 #157 VOLUNTARYHardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_012) hv:phyp pSeriesCall Trace: dump_stack_lvl+0x88/0xc4 (unreliable) print_report+0x214/0x63c kasan_report_invalid_free+0xe4/0x110 check_slab_allocation+0x100/0x150 kmem_cache_free+0x128/0x6e0 kasan_remove_zero_shadow+0x9c4/0xa20 memunmap_pages+0x2b8/0x5c0 devm_action_release+0x54/0x70 release_nodes+0xc8/0x1a0 devres_release_all+0xe0/0x140 device_unbind_cleanup+0x30/0x120 device_release_driver_internal+0x3e4/0x450 unbind_store+0xfc/0x110 drv_attr_store+0x78/0xb0 sysfs_kf_write+0x114/0x140 kernfs_fop_write_iter+0x264/0x3f0 vfs_write+0x3bc/0x7d0 ksys_write+0xa4/0x190 system_call_exception+0x190/0x480 system_call_vectored_common+0x15c/0x2ec---- interrupt: 3000 at 0x7fff93b3d3f4NIP: 00007fff93b3d3f4 LR: 00007fff93b3d3f4 CTR: 0000000000000000REGS: c0000003f1b07e80 TRAP: 3000 Not tainted (6.19.0-rc1-00048-gea1013c15392)MSR: 800000000280f033 CR: 48888208 XER: 00000000<...>NIP [00007fff93b3d3f4] 0x7fff93b3d3f4LR [00007fff93b3d3f4] 0x7fff93b3d3f4---- interrupt: 3000 The buggy address belongs to the object at c0000003c38e0000 which belongs to the cache pgtable-2^9 of size 4096 The buggy address is located 0 bytes inside of 4096-byte region [c0000003c38e0000, c0000003c38e1000) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3c38c head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 memcg:c0000003bfd63e01 flags: 0x63ffff800000040(head|node=6|zone=0|lastcpupid=0x7ffff) page_type: f5(slab) raw: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 head: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000002 c00c000000f0e301 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected[ 138.953636] [ T2164] Memory state around the buggy address:[ 138.953643] [ T2164] c0000003c38dff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 138.953652] [ T2164] c0000003c38dff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 138.953661] [ T2164] >c0000003c38e0000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 138.953669] [ T2164] ^[ 138.953675] [ T2164] c0000003c38e0080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 138.953684] [ T2164] c0000003c38e0100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 138.953692] [ T2164] ==================================================================[ 138.953701] [ T2164] Disabling lock debugging due to kernel taint
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix signed integer overflow in l2tp_ip6_sendmsgWhen len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will beoverflow. To fix, we can follow what udpv6 does and subtract thetranshdrlen from the max.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix signed integer overflow in __ip6_append_dataResurrect ubsan overflow checks and ubsan report this warning,fix it by change the variable [length] type to size_t.UBSAN: signed-integer-overflow in net/ipv6/ip6_output.c:1489:192147479552 + 8567 cannot be represented in type 'int'CPU: 0 PID: 253 Comm: err Not tainted 5.16.0+ #1Hardware name: linux,dummy-virt (DT)Call trace: dump_backtrace+0x214/0x230 show_stack+0x30/0x78 dump_stack_lvl+0xf8/0x118 dump_stack+0x18/0x30 ubsan_epilogue+0x18/0x60 handle_overflow+0xd0/0xf0 __ubsan_handle_add_overflow+0x34/0x44 __ip6_append_data.isra.48+0x1598/0x1688 ip6_append_data+0x128/0x260 udpv6_sendmsg+0x680/0xdd0 inet6_sendmsg+0x54/0x90 sock_sendmsg+0x70/0x88 ____sys_sendmsg+0xe8/0x368 ___sys_sendmsg+0x98/0xe0 __sys_sendmmsg+0xf4/0x3b8 __arm64_sys_sendmmsg+0x34/0x48 invoke_syscall+0x64/0x160 el0_svc_common.constprop.4+0x124/0x300 do_el0_svc+0x44/0xc8 el0_svc+0x3c/0x1e8 el0t_64_sync_handler+0x88/0xb0 el0t_64_sync+0x16c/0x170Changes since v1:-Change the variable [length] type to unsigned, as Eric Dumazet suggested.Changes since v2:-Don't change exthdrlen type in ip6_make_skb, as Paolo Abeni suggested.Changes since v3:-Don't change ulen type in udpv6_sendmsg and l2tp_ip6_sendmsg, asJakub Kicinski suggested.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hsr: Fix uninit-value access in fill_frame_info()Syzbot reports the following uninit-value access problem.=====================================================BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:601 [inline]BUG: KMSAN: uninit-value in hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 fill_frame_info net/hsr/hsr_forward.c:601 [inline] hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 hsr_dev_xmit+0x192/0x330 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4889 [inline] netdev_start_xmit include/linux/netdevice.h:4903 [inline] xmit_one net/core/dev.c:3544 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3560 __dev_queue_xmit+0x34d0/0x52a0 net/core/dev.c:4340 dev_queue_xmit include/linux/netdevice.h:3082 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [inline] __se_sys_sendto net/socket.c:2184 [inline] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82Uninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x148/0x470 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:644 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6299 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2794 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [inline] __se_sys_sendto net/socket.c:2184 [inline] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82It is because VLAN not yet supported in hsr driver. Return errorwhen protocol is ETH_P_8021Q in fill_frame_info() now to fix it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to avoid use-after-free for cached IPU bioxfstest generic/019 reports a bug:kernel BUG at mm/filemap.c:1619!RIP: 0010:folio_end_writeback+0x8a/0x90Call Trace: end_page_writeback+0x1c/0x60 f2fs_write_end_io+0x199/0x420 bio_endio+0x104/0x180 submit_bio_noacct+0xa5/0x510 submit_bio+0x48/0x80 f2fs_submit_write_bio+0x35/0x300 f2fs_submit_merged_ipu_write+0x2a0/0x2b0 f2fs_write_single_data_page+0x838/0x8b0 f2fs_write_cache_pages+0x379/0xa30 f2fs_write_data_pages+0x30c/0x340 do_writepages+0xd8/0x1b0 __writeback_single_inode+0x44/0x370 writeback_sb_inodes+0x233/0x4d0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x1dd/0x2d0 wb_workfn+0x367/0x4a0 process_one_work+0x21d/0x430 worker_thread+0x4e/0x3c0 kthread+0x103/0x130 ret_from_fork+0x2c/0x50The root cause is: after cp_error is set, f2fs_submit_merged_ipu_write()in f2fs_write_single_data_page() tries to flush IPU bio in cache, howeverf2fs_submit_merged_ipu_write() missed to check validity of @bio parameter,result in submitting random cached bio which belong to other IO context,then it will cause use-after-free issue, fix it by adding additionalvalidity check.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: fix uninit-value use in udf_get_fileshortadCheck for overflow when computing alen in udf_current_aext to mitigatelater uninit-value use in udf_get_fileshortad KMSAN bug[1].After applying the patch reproducer did not trigger any issue[2].[1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df[2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix out-of-bounds write in trie_get_next_key()trie_get_next_key() allocates a node stack with size trie->max_prefixlen,while it writes (trie->max_prefixlen + 1) nodes to the stack when it hasfull paths from the root to leaves. For example, consider a trie withmax_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ...0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with.prefixlen = 8 make 9 nodes be written on the node stack with size 8.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix out of bounds reads when finding clock sourcesThe current USB-audio driver code doesn't check bLength of eachdescriptor at traversing for clock descriptors. That is, when adevice provides a bogus descriptor with a shorter bLength, the drivermight hit out-of-bounds reads.For addressing it, this patch adds sanity checks to the validatorfunctions for the clock descriptor traversal. When the descriptorlength is shorter than expected, it's skipped in the loop.For the clock source and clock multiplier descriptors, we can justcheck bLength against the sizeof() of each descriptor type.OTOH, the clock selector descriptor of UAC2 and UAC3 has an arrayof bNrInPins elements and two more fields at its tail, hence thosehave to be checked in addition to the sizeof() check.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat/qat_4xxx - fix off by one in uof_get_name()The fw_objs[] array has "num_objs" elements so the > needs to be >= toprevent an out of bounds read.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: check for overflows in io_pin_pagesWARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0Call Trace: __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183 io_rings_map io_uring/io_uring.c:2611 [inline] io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470 io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692 io_uring_setup io_uring/io_uring.c:3781 [inline] ... io_pin_pages()'s uaddr parameter came directly from the user and can begarbage. Don't just add size to it as it can overflow.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: fix potential array underflow in ucsi_ccg_sync_control()The "command" variable can be controlled by the user via debugfs. Theworry is that if con_index is zero then "&uc->ucsi->connector[con_index- 1]" would be an array underflow.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: release svc_expkey/svc_export with rcu_workThe last reference for `cache_head` can be reduced to zero in `c_show`and `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently,`svc_export_put` and `expkey_put` will be invoked, leading to twoissues:1. The `svc_export_put` will directly free ex_uuid. However, `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can trigger a use-after-free issue, shown below. ================================================================== BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd] Read of size 1 at addr ff11000010fdc120 by task cat/870 CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dump_stack_lvl+0x53/0x70 print_address_description.constprop.0+0x2c/0x3a0 print_report+0xb9/0x280 kasan_report+0xae/0xe0 svc_export_show+0x362/0x430 [nfsd] c_show+0x161/0x390 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 830: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc_node_track_caller_noprof+0x1bc/0x400 kmemdup_noprof+0x22/0x50 svc_export_parse+0x8a9/0xb80 [nfsd] cache_do_downcall+0x71/0xa0 [sunrpc] cache_write_procfs+0x8e/0xd0 [sunrpc] proc_reg_write+0xe1/0x140 vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 868: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kfree+0xf3/0x3e0 svc_export_put+0x87/0xb0 [nfsd] cache_purge+0x17f/0x1f0 [sunrpc] nfsd_destroy_serv+0x226/0x2d0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e2. We cannot sleep while using `rcu_read_lock`/`rcu_read_unlock`. However, `svc_export_put`/`expkey_put` will call path_put, which subsequently triggers a sleeping operation due to the following `dput`. ============================= WARNING: suspicious RCU usage 5.10.0-dirty #141 Not tainted ----------------------------- ... Call Trace: dump_stack+0x9a/0xd0 ___might_sleep+0x231/0x240 dput+0x39/0x600 path_put+0x1b/0x30 svc_export_put+0x17/0x80 e_show+0x1c9/0x200 seq_read_iter+0x63f/0x7c0 seq_read+0x226/0x2d0 vfs_read+0x113/0x2c0 ksys_read+0xc9/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1Fix these issues by using `rcu_work` to help release`svc_expkey`/`svc_export`. This approach allows for an asynchronouscontext to invoke `path_put` and also facilitates the freeing of`uuid/exp/key` after an RCU grace period.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctlFix an issue detected by syzbot with KASAN:BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/core.c:416 [inline]BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0drivers/acpi/nfit/core.c:459The issue occurs in cmd_to_func when the call_pkg->nd_reserved2array is accessed without verifying that call_pkg points to a bufferthat is appropriately sized as a struct nd_cmd_pkg. This can leadto out-of-bounds access and undefined behavior if the buffer does nothave sufficient space.To address this, a check was added in acpi_nfit_ctl() to ensure thatbuf is not NULL and that buf_len is less than sizeof(*call_pkg)before accessing it. This ensures safe access to the members ofcall_pkg, including the nd_reserved2 array.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/uverbs: Prevent integer overflow issueIn the expression "cmd.wqe_size * cmd.wr_count", both variables are u32values that come from the user so the multiplication can lead to integerwrapping. Then we pass the result to uverbs_request_next_ptr() which alsocould potentially wrap. The "cmd.sge_count * sizeof(struct ib_uverbs_sge)"multiplication can also overflow on 32bit systems although it's fine on64bit systems.This patch does two things. First, I've re-arranged the condition inuverbs_request_next_ptr() so that the use controlled variable "len" is onone side of the comparison by itself without any math. Then I've modifiedall the callers to use size_mul() for the multiplications.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAXShifting 1 << 31 on a 32-bit int causes signed integer overflow, whichleads to undefined behavior. To prevent this, cast 1 to u32 beforeperforming the shift, ensuring well-defined behavior.This change explicitly avoids any potential overflow by ensuring thatthe shift occurs on an unsigned 32-bit integer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: Stack-based buffer overflow in libtasn1 version: v4.20.0. The function fails to validate the size of input data resulting in a buffer overflow in asn1_expend_octet_string.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libtasn1 > 0-0 (version in image is 4.13-150000.4.14.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/rose: prevent integer overflows in rose_setsockopt()In case of possible unpredictably large arguments passed torose_setsockopt() and multiplied by extra values on top of that,integer overflows may occur.Do the safest minimum and fix these issues by checking thecontents of 'opt' and returning -EINVAL if they are too large. Also,switch to unsigned int and remove useless check for negative 'opt'in ROSE_IDLE case.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: add missing rcu read protection for procfs contentWhen the procfs content is generated for a bcm_op which is in the processto be removed the procfs output might show unreliable data (UAF).As the removal of bcm_op's is already implemented with rcu handling thispatch adds the missing rcu_read_lock() and makes sure the list entriesare properly removed under rcu protection.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix error flow upon firmware failure for RQ destructionUpon RQ destruction if the firmware command fails which is thelast resource to be destroyed some SW resources were already cleanedregardless of the failure.Now properly rollback the object to its original state upon such failure.In order to avoid a use-after free in case someone tries to destroy theobject again, which results in the following kernel trace:refcount_t: underflow; use-after-free.WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) rfkill mlx5_core(OE) mlxdevm(OE) ib_uverbs(OE) ib_core(OE) psample mlxfw(OE) mlx_compat(OE) macsec tls pci_hyperv_intf sunrpc vfat fat virtio_net net_failover failover fuse loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_console virtio_gpu virtio_blk virtio_dma_buf virtio_mmio dm_mirror dm_region_hash dm_log dm_mod xpmem(OE)CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G OE ------- --- 6.12.0-54.el10.aarch64 #1Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULEHardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : refcount_warn_saturate+0xf4/0x148lr : refcount_warn_saturate+0xf4/0x148sp : ffff80008b81b7e0x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37fx14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fffx5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600Call trace: refcount_warn_saturate+0xf4/0x148 mlx5_core_put_rsc+0x88/0xa0 [mlx5_ib] mlx5_core_destroy_rq_tracked+0x64/0x98 [mlx5_ib] mlx5_ib_destroy_wq+0x34/0x80 [mlx5_ib] ib_destroy_wq_user+0x30/0xc0 [ib_core] uverbs_free_wq+0x28/0x58 [ib_uverbs] destroy_hw_idr_uobject+0x34/0x78 [ib_uverbs] uverbs_destroy_uobject+0x48/0x240 [ib_uverbs] __uverbs_cleanup_ufile+0xd4/0x1a8 [ib_uverbs] uverbs_destroy_ufile_hw+0x48/0x120 [ib_uverbs] ib_uverbs_close+0x2c/0x100 [ib_uverbs] __fput+0xd8/0x2f0 __fput_sync+0x50/0x70 __arm64_sys_close+0x40/0x90 invoke_syscall.constprop.0+0x74/0xd0 do_el0_svc+0x48/0xe8 el0_svc+0x44/0x1d0 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x1a4/0x1a8
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: prevent overflow in lookup table allocationWhen calculating the lookup table size, ensure the followingmultiplication does not overflow:- desc->field_len[] maximum value is U8_MAX multiplied by NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case.- NFT_PIPAPO_BUCKETS(f->bb) is 2^8, worst case.- sizeof(unsigned long), from sizeof(*f->lt), lt in struct nft_pipapo_field.Then, use check_mul_overflow() to multiply by bucket size and then usecheck_add_overflow() to the alignment for avx2 (if needed). Finally, addlt_size_check_overflow() helper and use it to consolidate this.While at it, replace leftover allocation using the GFP_KERNEL toGFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix ktls panic with sockmap[ 2172.936997] ------------[ cut here ]------------[ 2172.936999] kernel BUG at lib/iov_iter.c:629!......[ 2172.944996] PKRU: 55555554[ 2172.945155] Call Trace:[ 2172.945299] [ 2172.945428] ? die+0x36/0x90[ 2172.945601] ? do_trap+0xdd/0x100[ 2172.945795] ? iov_iter_revert+0x178/0x180[ 2172.946031] ? iov_iter_revert+0x178/0x180[ 2172.946267] ? do_error_trap+0x7d/0x110[ 2172.946499] ? iov_iter_revert+0x178/0x180[ 2172.946736] ? exc_invalid_op+0x50/0x70[ 2172.946961] ? iov_iter_revert+0x178/0x180[ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20[ 2172.947446] ? iov_iter_revert+0x178/0x180[ 2172.947683] ? iov_iter_revert+0x5c/0x180[ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840[ 2172.948206] tls_sw_sendmsg+0x52/0x80[ 2172.948420] ? inet_sendmsg+0x1f/0x70[ 2172.948634] __sys_sendto+0x1cd/0x200[ 2172.948848] ? find_held_lock+0x2b/0x80[ 2172.949072] ? syscall_trace_enter+0x140/0x270[ 2172.949330] ? __lock_release.isra.0+0x5e/0x170[ 2172.949595] ? find_held_lock+0x2b/0x80[ 2172.949817] ? syscall_trace_enter+0x140/0x270[ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190[ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0[ 2172.951036] __x64_sys_sendto+0x24/0x30[ 2172.951382] do_syscall_64+0x90/0x170......After calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase,e.g., when the BPF program executes bpf_msg_push_data().If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes,it will return -ENOSPC and attempt to roll back to the non-zero copylogic. However, during rollback, msg->msg_iter is reset, but sincemsg_pl->sg.size has been increased, subsequent executions will exceed theactual size of msg_iter.'''iov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size);'''The changes in this commit are based on the following considerations:1. When cork_bytes is set, rolling back to non-zero copy logic ispointless and can directly go to zero-copy logic.2. We can not calculate the correct number of bytes to revert msg_iter.Assume the original data is "abcdefgh" (8 bytes), and after 3 pushesby the BPF program, it becomes 11-byte data: "abc?de?fgh?".Then, we set cork_bytes to 6, which means the first 6 bytes have beenprocessed, and the remaining 5 bytes "?fgh?" will be cached until thelength meets the cork_bytes requirement.However, some data in "?fgh?" is not within 'sg->msg_iter'(but in msg_pl instead), especially the data "?" we pushed.So it doesn't seem as simple as just reverting through an offset ofmsg_iter.3. For non-TLS sockets in tcp_bpf_sendmsg, when a "cork" situation occurs,the user-space send() doesn't return an error, and the returned length isthe same as the input length parameter, even if some data is cached.Additionally, I saw that the current non-zero-copy logic for handlingcorking is written as:'''line 1177else if (ret != -EAGAIN) { if (ret == -ENOSPC) ret = 0; goto send_end;'''So it's ok to just return 'copied' without error when a "cork" situationoccurs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: gpio: Fix the out-of-bounds access to drvdata::gpiodsdrvdata::gpiods is supposed to hold an array of 'gpio_desc' pointers. Butthe memory is allocated for only one pointer. This will lead toout-of-bounds access later in the code if 'config::ngpios' is > 1. Sofix the code to allocate enough memory to hold 'config::ngpios' of GPIOdescriptors.While at it, also move the check for memory allocation failure to be belowthe allocation to make it more readable.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:genirq/irq_sim: Initialize work context pointers properlyInitialize `ops` member's pointers properly by using kzalloc() instead ofkmalloc() when allocating the simulation work context. Otherwise thepointers contain random content leading to invalid dereferencing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/gem: Acquire references on GEM handles for framebuffersA GEM handle can be released while the GEM buffer object is attachedto a DRM framebuffer. This leads to the release of the dma-buf backingthe buffer object, if any. [1] Trying to use the framebuffer in furthermode-setting operations leads to a segmentation fault. Most easilyhappens with driver that use shadow planes for vmap-ing the dma-bufduring a page flip. An example is shown below.[ 156.791968] ------------[ cut here ]------------[ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430[...][ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430[ 157.043420] Call Trace:[ 157.045898] [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0[ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0[ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0[ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710[ 157.065567] ? dma_buf_vmap+0x224/0x430[ 157.069446] ? __warn.cold+0x58/0xe4[ 157.073061] ? dma_buf_vmap+0x224/0x430[ 157.077111] ? report_bug+0x1dd/0x390[ 157.080842] ? handle_bug+0x5e/0xa0[ 157.084389] ? exc_invalid_op+0x14/0x50[ 157.088291] ? asm_exc_invalid_op+0x16/0x20[ 157.092548] ? dma_buf_vmap+0x224/0x430[ 157.096663] ? dma_resv_get_singleton+0x6d/0x230[ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10[ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10[ 157.110697] drm_gem_shmem_vmap+0x74/0x710[ 157.114866] drm_gem_vmap+0xa9/0x1b0[ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0[ 157.123086] drm_gem_fb_vmap+0xab/0x300[ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10[ 157.133032] ? lockdep_init_map_type+0x19d/0x880[ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0[ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180[ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40[...][ 157.346424] ---[ end trace 0000000000000000 ]---Acquiring GEM handles for the framebuffer's GEM buffer objects preventsthis from happening. The framebuffer's cleanup later puts the handlereferences.Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM objectinstance") triggers the segmentation fault easily by using the dma-buffield more widely. The underlying issue with reference counting hasbeen present before.v2:- acquire the handle instead of the BO (Christian)- fix comment style (Christian)- drop the Fixes tag (Christian)- rename err_ gotos- add missing Link tag
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flightReject migration of SEV{-ES} state if either the source or destination VMis actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in thesection between incrementing created_vcpus and online_vcpus. The bulk ofvCPU creation runs _outside_ of kvm->lock to allow creating multiple vCPUsin parallel, and so sev_info.es_active can get toggled from false=>true inthe destination VM after (or during) svm_vcpu_create(), resulting in anSEV{-ES} VM effectively having a non-SEV{-ES} vCPU.The issue manifests most visibly as a crash when trying to free a vCPU'sNULL VMSA page in an SEV-ES VM, but any number of things can go wrong. BUG: unable to handle page fault for address: ffffebde00000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024 RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline] RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline] RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline] RIP: 0010:PageHead include/linux/page-flags.h:866 [inline] RIP: 0010:___free_pages+0x3e/0x120 mm/page_alloc.c:5067 Code: <49> f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0 RSP: 0018:ffff8984551978d0 EFLAGS: 00010246 RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000 RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000 R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000 R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000 FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0 DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169 svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515 kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396 kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline] kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490 kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895 kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310 kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369 __fput+0x3e4/0x9e0 fs/file_table.c:465 task_work_run+0x1a9/0x220 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x7f0/0x25b0 kernel/exit.c:953 do_group_exit+0x203/0x2d0 kernel/exit.c:1102 get_signal+0x1357/0x1480 kernel/signal.c:3034 arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218 do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f87a898e969 Modules linked in: gq(O) gsmi: Log Shutdown Reason 0x03 CR2: ffffebde00000000 ---[ end trace 0000000000000000 ]---Deliberately don't check for a NULL VMSA when freeing the vCPU, as crashingthe host is likely desirable due to the VMSA being consumed by hardware.E.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write abogus VMSA page. Accessing P---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf: Revert to requiring CAP_SYS_ADMIN for uprobesJann reports that uprobes can be used destructively when used in themiddle of an instruction. The kernel only verifies there is a validinstruction at the requested offset, but due to variable instructionlength cannot determine if this is an instruction as seen by theintended execution stream.Additionally, Mark Rutland notes that on architectures that mix datain the text segment (like arm64), a similar things can be done if thedata word is 'mistaken' for an instruction.As such, require CAP_SYS_ADMIN for uprobes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: Harden s32ton() against conversion to 0 bitsTesting by the syzbot fuzzer showed that the HID core gets ashift-out-of-bounds exception when it tries to convert a 32-bitquantity to a 0-bit quantity. Ideally this should never occur, butthere are buggy devices and some might have a report field with sizeset to zero; we shouldn't reject the report or the device just becauseof that.Instead, harden the s32ton() routine so that it returns a reasonableresult instead of crashing when it is called with the number of bitsset to 0 -- the same as what snto32() does.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pptp: ensure minimal skb length in pptp_xmit()Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb dataon ppp_sync_txmung") fixed ppp_sync_txmunge()We need a similar fix in pptp_xmit(), otherwise we mightread uninit data as reported by syzbot.BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline] ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314 pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x893/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtl818x: Kill URBs before clearing tx status queueIn rtl8187_stop() move the call of usb_kill_anchored_urbs() before clearingb_tx_status.queue. This change prevents callbacks from using already freedskb due to anchor was not killed before freeing such skb. BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted 6.15.0 #8 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:ieee80211_tx_status_irqsafe+0x21/0xc0 [mac80211] Call Trace: rtl8187_tx_cb+0x116/0x150 [rtl8187] __usb_hcd_giveback_urb+0x9d/0x120 usb_giveback_urb_bh+0xbb/0x140 process_one_work+0x19b/0x3c0 bh_worker+0x1a7/0x210 tasklet_action+0x10/0x30 handle_softirqs+0xf0/0x340 __irq_exit_rcu+0xcd/0xf0 common_interrupt+0x85/0xa0 Tested on RTL8187BvE device.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wilc1000: avoid buffer overflow in WID string configurationFix the following copy overflow warning identified by Smatch checker. drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame() error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537)This patch introduces size check before accessing the memory buffer.The checks are base on the WID type of received data from the firmware.For WID string configuration, the size limit is determined by individualelement size in 'struct wilc_cfg_str_vals' that is maintained in 'len' fieldof 'struct wilc_cfg_str'.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix idx validation in config queues msgEnsure idx is within range of active/initialized TCs when iterating overvf->ch[idx] in i40e_vc_config_queues_msg().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI/IOV: Fix race between SR-IOV enable/disable and hotplugCommit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking whenenabling/disabling SR-IOV") tried to fix a race between the VF removalinside sriov_del_vfs() and concurrent hot unplug by taking the PCIrescan/remove lock in sriov_del_vfs(). Similarly the PCI rescan/remove lockwas also taken in sriov_add_vfs() to protect addition of VFs.This approach however causes deadlock on trying to remove PFs with SR-IOVenabled because PFs disable SR-IOV during removal and this removal happensunder the PCI rescan/remove lock. So the original fix had to be reverted.Instead of taking the PCI rescan/remove lock in sriov_add_vfs() andsriov_del_vfs(), fix the race that occurs with SR-IOV enable and disable vshotplug higher up in the callchain by taking the lock insriov_numvfs_store() before calling into the driver's sriov_configure()callback.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAFThere is a KASAN: slab-use-after-free read in btusb_disconnect().Calling "usb_driver_release_interface(&btusb_driver, data->intf)" willfree the btusb data associated with the interface. The same data isthen used later in the function, hence the UAF.Fix by moving the accesses to btusb data to before the data is free'd.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:team: Move team device type change at the end of team_port_addAttempting to add a port device that is already up will expectedly fail,but not before modifying the team device header_ops.In the case of the syzbot reproducer the gre0 device isalready in state UP when it attempts to add it as aport device of team0, this fails but before thatheader_ops->create of team0 is changed from eth_header to ipgre_headerin the call to team_dev_type_check_change.Later when we end up in ipgre_header() struct ip_tunnel* points to nonsenseas the private data of the device still holds a struct team.Example sequence of iproute2 commands to reproduce the hang/BUG():ip link add dev team0 type teamip link add dev gre0 type greip link set dev gre0 upip link set dev gre0 master team0ip link set dev team0 upping -I team0 1.1.1.1Move team_dev_type_check_change down where all other checks have passedas it changes the dev type with no way to restore it in caseone of the checks that follow it fail.Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from devThis is done by adding a conditional before the call to dev_set_mtuto prevent it from assigning port_dev->mtu = dev->mtu and insteadletting team_dev_type_check_change assign dev->mtu = port_dev->mtu.The conditional is needed because the patch moves the call toteam_dev_type_check_change past dev_set_mtu.Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: potential integer overflow in usbg_make_tpg()The variable tpgt in usbg_make_tpg() is defined as unsigned long and isassigned to tpgt->tport_tpgt, which is defined as u16. This may cause aninteger overflow when tpgt is greater than USHRT_MAX (65535). Ihaven't tried to trigger it myself, but it is possible to trigger itby calling usbg_make_tpg() with a large value for tpgt.I modified the type of tpgt to match tpgt->tport_tpgt and adjusted therelevant code accordingly.This patch is similar to commit 59c816c1f24d ("vhost/scsi: potentialmemory corruption").
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - zero initialize memory allocated via sock_kmallocSeveral crypto user API contexts and requests allocated withsock_kmalloc() were left uninitialized, relying on callers toset fields explicitly. This resulted in the use of uninitializeddata in certain error paths or when new fields are added in thefuture.The ACVP patches also contain two user-space interface files:algif_kpp.c and algif_akcipher.c. These too rely on properinitialization of their context structures.A particular issue has been observed with the newly added'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")Because the context is not memset to zero after allocation,the inflight variable has contained garbage values. As a result,af_alg_alloc_areq() has incorrectly returned -EBUSY randomly whenthe garbage value was interpreted as true: https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209The check directly tests ctx->inflight without explicitlycomparing against true/false. Since inflight is only ever set totrue or false later, an uninitialized value has triggered-EBUSY failures. Zero-initializing memory allocated withsock_kmalloc() ensures inflight and other fields start in a knownstate, removing random issues caused by uninitialized data.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()Blamed commit did not take care of VLAN encapsulationsas spotted by syzbot [1].Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull().[1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729 __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860 ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903 gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1 ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500 ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:318 [inline] ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311 __netif_receive_skb_one_core net/core/dev.c:6139 [inline] __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252 netif_receive_skb_internal net/core/dev.c:6338 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6397 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4960 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586 __alloc_skb+0x805/0x1040 net/core/skbuff.c:690 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712 sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995 tun_alloc_skb drivers/net/tun.c:1461 [inline] tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()When ec_install_handlers() returns -EPROBE_DEFER on reduced-hardwareplatforms, it has already started the EC and installed the addressspace handler with the struct acpi_ec pointer as handler context.However, acpi_ec_setup() propagates the error without any cleanup.The caller acpi_ec_add() then frees the struct acpi_ec for non-bootinstances, leaving a dangling handler context in ACPICA.Any subsequent AML evaluation that accesses an EC OpRegion fielddispatches into acpi_ec_space_handler() with the freed pointer,causing a use-after-free: BUG: KASAN: slab-use-after-free in mutex_lock (kernel/locking/mutex.c:289) Write of size 8 at addr ffff88800721de38 by task init/1 Call Trace: mutex_lock (kernel/locking/mutex.c:289) acpi_ec_space_handler (drivers/acpi/ec.c:1362) acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293) acpi_ex_access_region (drivers/acpi/acpica/exfldio.c:246) acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio.c:509) acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700) acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327) acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392) Allocated by task 1: acpi_ec_alloc (drivers/acpi/ec.c:1424) acpi_ec_add (drivers/acpi/ec.c:1692) Freed by task 1: kfree (mm/slub.c:6876) acpi_ec_add (drivers/acpi/ec.c:1751)The bug triggers on reduced-hardware EC platforms (ec->gpe < 0)when the GPIO IRQ provider defers probing. Once the stale handlerexists, any unprivileged sysfs read that causes AML to touch anEC OpRegion (battery, thermal, backlight) exercises the danglingpointer.Fix this by calling ec_remove_handlers() in the error path ofacpi_ec_setup() before clearing first_ec. ec_remove_handlers()checks each EC_FLAGS_* bit before acting, so it is safe to callregardless of how far ec_install_handlers() progressed: -ENODEV (handler not installed): only calls acpi_ec_stop() -EPROBE_DEFER (handler installed): removes handler, stops EC
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Buffer overflow in drivers/xen/sys-hypervisor.cThe build id returned by HYPERVISOR_xen_version(XENVER_build_id) isneither NUL terminated nor a string.The first causes a buffer overflow as sprintf in buildid_show willread and copy till it finds a NUL.00000000 f4 91 51 f4 dd 38 9e 9d 65 47 52 eb 10 71 db 50 |..Q..8..eGR..q.P|00000010 b9 a8 01 42 6f 2e 32 |...Bo.2|00000017So use a memcpy instead of sprintf to have the correct value:00000000 f4 91 51 f4 dd 00 9e 9d 65 47 52 eb 10 71 db 50 |..Q.....eGR..q.P|00000010 b9 a8 01 42 |...B|00000014(the above have a hack to embed a zero inside and check it'sreturned correctly).This is XSA-485 / CVE-2026-31786
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: jq is a command-line JSON processor. In 1.8.1 and earlier, jv_contains recurses into nested arrays/objects with no depth limit. With a sufficiently nested input structure (built programmatically with reduce, since the JSON parser caps at depth 10000), the C stack is exhausted.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- vim > 0-0 (version in image is 9.2.0280-150500.20.46.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: vidtv: fix pass-by-value structs causing MSAN warningsvidtv_ts_null_write_into() and vidtv_ts_pcr_write_into() take theirargument structs by value, causing MSAN to report uninit-value warnings.While only vidtv_ts_null_write_into() has triggered a report so far,both functions share the same issue.Fix by passing both structs by const pointer instead, avoiding thestack copy of the struct along with its MSAN shadow and origin metadata.The functions do not modify the structs, which is enforced by the constqualifier.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- vim > 0-0 (version in image is 9.2.0280-150500.20.46.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential OOBs in smb2_parse_contexts()Validate offsets and lengths before dereferencing create contexts insmb2_parse_contexts().This fixes following oops when accessing invalid create contexts fromserver: BUG: unable to handle page fault for address: ffff8881178d8cc3 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 4a01067 P4D 4a01067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs] Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00 00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7 7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00 RSP: 0018:ffffc900007939e0 EFLAGS: 00010216 RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90 RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000 RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000 R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000 R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22 FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x181/0x480 ? search_module_extables+0x19/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? exc_page_fault+0x1b6/0x1c0 ? asm_exc_page_fault+0x26/0x30 ? smb2_parse_contexts+0xa0/0x3a0 [cifs] SMB2_open+0x38d/0x5f0 [cifs] ? smb2_is_path_accessible+0x138/0x260 [cifs] smb2_is_path_accessible+0x138/0x260 [cifs] cifs_is_path_remote+0x8d/0x230 [cifs] cifs_mount+0x7e/0x350 [cifs] cifs_smb3_do_mount+0x128/0x780 [cifs] smb3_get_tree+0xd9/0x290 [cifs] vfs_get_tree+0x2c/0x100 ? capable+0x37/0x70 path_mount+0x2d7/0xb80 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 __x64_sys_mount+0x11a/0x150 do_syscall_64+0x47/0xf0 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f8737657b1e
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: check send stream number after wait_for_sndbufThis patch fixes a corner case where the asoc out stream count may changeafter wait_for_sndbuf.When the main thread in the client starts a connection, if its out streamcount is set to N while the in stream count in the server is set to N - 2,another thread in the client keeps sending the msgs with stream numberN - 1, and waits for sndbuf before processing INIT_ACK.However, after processing INIT_ACK, the out stream count in the client isshrunk to N - 2, the same to the in stream count in the server. The crashoccurs when the thread waiting for sndbuf is awake and sends the msg in anon-existing stream(N - 1), the call trace is as below: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] Call Trace: sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1114 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1777 [inline] sctp_side_effects net/sctp/sm_sideeffect.c:1199 [inline] sctp_do_sm+0x197d/0x5310 net/sctp/sm_sideeffect.c:1170 sctp_primitive_SEND+0x9f/0xc0 net/sctp/primitive.c:163 sctp_sendmsg_to_asoc+0x10eb/0x1a30 net/sctp/socket.c:1868 sctp_sendmsg+0x8d4/0x1d90 net/sctp/socket.c:2026 inet_sendmsg+0x9d/0xe0 net/ipv4/af_inet.c:825 sock_sendmsg_nosec net/socket.c:722 [inline] sock_sendmsg+0xde/0x190 net/socket.c:745The fix is to add an unlikely check for the send stream number after thethread wakes up from the wait_for_sndbuf.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: do not update mtu if msg_max is too small in mtu negotiationWhen doing link mtu negotiation, a malicious peer may send Activate msgwith a very small mtu, e.g. 4 in Shuang's testing, without checking forthe minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), thenn->links[bearer_id].mtu is set to 4294967228, which is a overflow of'4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss().With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning: tipc: Too large msg, purging xmit list 1 5 0 40 4! tipc: Too large msg, purging xmit list 1 15 0 60 4!And with tipc_link_entry.mtu 4294967228, a huge skb was allocated innamed_distribute(), and when purging it in tipc_link_xmit(), a crashwas even caused: general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19 RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0 Call Trace: skb_release_data+0xf9/0x1d0 kfree_skb_reason+0x40/0x100 tipc_link_xmit+0x57a/0x740 [tipc] tipc_node_xmit+0x16c/0x5c0 [tipc] tipc_named_node_up+0x27f/0x2c0 [tipc] tipc_node_write_unlock+0x149/0x170 [tipc] tipc_rcv+0x608/0x740 [tipc] tipc_udp_recv+0xdc/0x1f0 [tipc] udp_queue_rcv_one_skb+0x33e/0x620 udp_unicast_rcv_skb.isra.72+0x75/0x90 __udp4_lib_rcv+0x56d/0xc20 ip_protocol_deliver_rcu+0x100/0x2d0This patch fixes it by checking the new mtu against tipc_bearer_min_mtu(),and not updating mtu if it is too small.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: qmi_encdec: Restrict string length in decodeThe QMI TLV value for strings in a lot of qmi element info structuresaccount for null terminated strings with MAX_LEN + 1. If a string isactually MAX_LEN + 1 length, this will cause an out of bounds accesswhen the NULL character is appended in decoding.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: cls_api: remove block_cb from driver_list before freeingError handler of tcf_block_bind() frees the whole bo->cb_list on error.However, by that time the flow_block_cb instances are already in the driverlist because driver ndo_setup_tc() callback is called before that up thecall chain in tcf_block_offload_cmd(). This leaves dangling pointers tofreed objects in the list and causes use-after-free[0]. Fix it by alsoremoving flow_block_cb instances from driver_list before deallocating them.[0]:[ 279.868433] ==================================================================[ 279.869964] BUG: KASAN: slab-use-after-free in flow_block_cb_setup_simple+0x631/0x7c0[ 279.871527] Read of size 8 at addr ffff888147e2bf20 by task tc/2963[ 279.873151] CPU: 6 PID: 2963 Comm: tc Not tainted 6.3.0-rc6+ #4[ 279.874273] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014[ 279.876295] Call Trace:[ 279.876882] [ 279.877413] dump_stack_lvl+0x33/0x50[ 279.878198] print_report+0xc2/0x610[ 279.878987] ? flow_block_cb_setup_simple+0x631/0x7c0[ 279.879994] kasan_report+0xae/0xe0[ 279.880750] ? flow_block_cb_setup_simple+0x631/0x7c0[ 279.881744] ? mlx5e_tc_reoffload_flows_work+0x240/0x240 [mlx5_core][ 279.883047] flow_block_cb_setup_simple+0x631/0x7c0[ 279.884027] tcf_block_offload_cmd.isra.0+0x189/0x2d0[ 279.885037] ? tcf_block_setup+0x6b0/0x6b0[ 279.885901] ? mutex_lock+0x7d/0xd0[ 279.886669] ? __mutex_unlock_slowpath.constprop.0+0x2d0/0x2d0[ 279.887844] ? ingress_init+0x1c0/0x1c0 [sch_ingress][ 279.888846] tcf_block_get_ext+0x61c/0x1200[ 279.889711] ingress_init+0x112/0x1c0 [sch_ingress][ 279.890682] ? clsact_init+0x2b0/0x2b0 [sch_ingress][ 279.891701] qdisc_create+0x401/0xea0[ 279.892485] ? qdisc_tree_reduce_backlog+0x470/0x470[ 279.893473] tc_modify_qdisc+0x6f7/0x16d0[ 279.894344] ? tc_get_qdisc+0xac0/0xac0[ 279.895213] ? mutex_lock+0x7d/0xd0[ 279.896005] ? __mutex_lock_slowpath+0x10/0x10[ 279.896910] rtnetlink_rcv_msg+0x5fe/0x9d0[ 279.897770] ? rtnl_calcit.isra.0+0x2b0/0x2b0[ 279.898672] ? __sys_sendmsg+0xb5/0x140[ 279.899494] ? do_syscall_64+0x3d/0x90[ 279.900302] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0[ 279.901337] ? kasan_save_stack+0x2e/0x40[ 279.902177] ? kasan_save_stack+0x1e/0x40[ 279.903058] ? kasan_set_track+0x21/0x30[ 279.903913] ? kasan_save_free_info+0x2a/0x40[ 279.904836] ? ____kasan_slab_free+0x11a/0x1b0[ 279.905741] ? kmem_cache_free+0x179/0x400[ 279.906599] netlink_rcv_skb+0x12c/0x360[ 279.907450] ? rtnl_calcit.isra.0+0x2b0/0x2b0[ 279.908360] ? netlink_ack+0x1550/0x1550[ 279.909192] ? rhashtable_walk_peek+0x170/0x170[ 279.910135] ? kmem_cache_alloc_node+0x1af/0x390[ 279.911086] ? _copy_from_iter+0x3d6/0xc70[ 279.912031] netlink_unicast+0x553/0x790[ 279.912864] ? netlink_attachskb+0x6a0/0x6a0[ 279.913763] ? netlink_recvmsg+0x416/0xb50[ 279.914627] netlink_sendmsg+0x7a1/0xcb0[ 279.915473] ? netlink_unicast+0x790/0x790[ 279.916334] ? iovec_from_user.part.0+0x4d/0x220[ 279.917293] ? netlink_unicast+0x790/0x790[ 279.918159] sock_sendmsg+0xc5/0x190[ 279.918938] ____sys_sendmsg+0x535/0x6b0[ 279.919813] ? import_iovec+0x7/0x10[ 279.920601] ? kernel_sendmsg+0x30/0x30[ 279.921423] ? __copy_msghdr+0x3c0/0x3c0[ 279.922254] ? import_iovec+0x7/0x10[ 279.923041] ___sys_sendmsg+0xeb/0x170[ 279.923854] ? copy_msghdr_from_user+0x110/0x110[ 279.924797] ? ___sys_recvmsg+0xd9/0x130[ 279.925630] ? __perf_event_task_sched_in+0x183/0x470[ 279.926656] ? ___sys_sendmsg+0x170/0x170[ 279.927529] ? ctx_sched_in+0x530/0x530[ 279.928369] ? update_curr+0x283/0x4f0[ 279.929185] ? perf_event_update_userpage+0x570/0x570[ 279.930201] ? __fget_light+0x57/0x520[ 279.931023] ? __switch_to+0x53d/0xe70[ 27---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: set page extent mapped after read_folio in relocate_one_pageOne of the CI runs triggered the following panic assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229 ------------[ cut here ]------------ kernel BUG at fs/btrfs/subpage.c:229! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 0 PID: 923660 Comm: btrfs Not tainted 6.5.0-rc3+ #1 pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_subpage_assert+0xbc/0xf0 lr : btrfs_subpage_assert+0xbc/0xf0 sp : ffff800093213720 x29: ffff800093213720 x28: ffff8000932138b4 x27: 000000000c280000 x26: 00000001b5d00000 x25: 000000000c281000 x24: 000000000c281fff x23: 0000000000001000 x22: 0000000000000000 x21: ffffff42b95bf880 x20: ffff42b9528e0000 x19: 0000000000001000 x18: ffffffffffffffff x17: 667274622f736620 x16: 6e69202c65746176 x15: 0000000000000028 x14: 0000000000000003 x13: 00000000002672d7 x12: 0000000000000000 x11: ffffcd3f0ccd9204 x10: ffffcd3f0554ae50 x9 : ffffcd3f0379528c x8 : ffff800093213428 x7 : 0000000000000000 x6 : ffffcd3f091771e8 x5 : ffff42b97f333948 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff42b9556cde80 x0 : 000000000000004f Call trace: btrfs_subpage_assert+0xbc/0xf0 btrfs_subpage_set_dirty+0x38/0xa0 btrfs_page_set_dirty+0x58/0x88 relocate_one_page+0x204/0x5f0 relocate_file_extent_cluster+0x11c/0x180 relocate_data_extent+0xd0/0xf8 relocate_block_group+0x3d0/0x4e8 btrfs_relocate_block_group+0x2d8/0x490 btrfs_relocate_chunk+0x54/0x1a8 btrfs_balance+0x7f4/0x1150 btrfs_ioctl+0x10f0/0x20b8 __arm64_sys_ioctl+0x120/0x11d8 invoke_syscall.constprop.0+0x80/0xd8 do_el0_svc+0x6c/0x158 el0_svc+0x50/0x1b0 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x194/0x198 Code: 91098021 b0007fa0 91346000 97e9c6d2 (d4210000)This is the same problem outlined in 17b17fcd6d44 ("btrfs:set_page_extent_mapped after read_folio in btrfs_cont_expand") , and thefix is the same. I originally looked for the same pattern elsewhere inour code, but mistakenly skipped over this code because I saw the pagecache readahead before we set_page_extent_mapped, not realizing thatthis was only in the !page case, that we can still end up with a!uptodate page and then do the btrfs_read_folio further down.The fix here is the same as the above mentioned patch, move theset_page_extent_mapped call to after the btrfs_read_folio() block tomake sure that we have the subpage blocksize stuff setup properly beforeusing the page.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: bridge: confirm multicast packets before passing them up the stackconntrack nf_confirm logic cannot handle cloned skbs referencingthe same nf_conn entry, which will happen for multicast (broadcast)frames on bridges. Example: macvlan0 | br0 / \ ethX ethY ethX (or Y) receives a L2 multicast or broadcast packet containing an IP packet, flow is not yet in conntrack table. 1. skb passes through bridge and fake-ip (br_netfilter)Prerouting. -> skb->_nfct now references a unconfirmed entry 2. skb is broad/mcast packet. bridge now passes clones out on each bridge interface. 3. skb gets passed up the stack. 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb and schedules a work queue to send them out on the lower devices. The clone skb->_nfct is not a copy, it is the same entry as the original skb. The macvlan rx handler then returns RX_HANDLER_PASS. 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.The Macvlan broadcast worker and normal confirm path will race.This race will not happen if step 2 already confirmed a clone. In thatcase later steps perform skb_clone() with skb->_nfct already confirmed (inhash table). This works fine.But such confirmation won't happen when eb/ip/nftables rules dropped thepackets before they reached the nf_confirm step in postrouting.Pablo points out that nf_conntrack_bridge doesn't allow use of statefulnat, so we can safely discard the nf_conn entry and let inet callconntrack again.This doesn't work for bridge netfilter: skb could have a nattransformation. Also bridge nf prevents re-invocation of inet preroutingvia 'sabotage_in' hook.Work around this problem by explicit confirmation of the entry at LOCAL_INtime, before upper layer has a chance to clone the unconfirmed entry.The downside is that this disables NAT and conntrack helpers.Alternative fix would be to add locking to all code parts that deal withunconfirmed packets, but even if that could be done in a sane way thisopens up other problems, for example:-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4-m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5For multicast case, only one of such conflicting mappings will becreated, conntrack only handles 1:1 NAT mappings.Users should set create a setup that explicitly marks such trafficNOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypassthem, ruleset might have accept rules for untracked traffic already,so user-visible behaviour would change.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: fix mptcp DSS corruption due to large pmtu xmitSyzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: URLs containing percent-encoded slashes (`/` or `\`) can trick wcurl intosaving the output file outside of the current directory without the userexplicitly asking for it.This flaw only affects the wcurl command line tool.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- curl > 0-0 (version in image is 8.14.1-150400.5.83.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- nfs-client > 0-0 (version in image is 2.1.1-150500.22.3.1).
-
Description: When reading an HTTP response from a server, if no read amount is specified, the default behavior will be to use Content-Length. This allows a malicious server to cause the client to read large amounts of data into memory, potentially causing OOM or other DoS.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- krb5 > 0-0 (version in image is 1.20.1-150500.3.17.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: Fix the dead loop of MPLS parseThe unexpected MPLS packet may not end with the bottom label stack.When there are many stacks, The label count value has wrapped around.A dead loop occurs, soft lockup/CPU stuck finally.stack backtrace:UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26index -1 is out of range for type '__be32 [3]'CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G OE 5.15.0-121-generic #131-UbuntuHardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021Call Trace: show_stack+0x52/0x5c dump_stack_lvl+0x4a/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x36 __ubsan_handle_out_of_bounds.cold+0x44/0x49 key_extract_l3l4+0x82a/0x840 [openvswitch] ? kfree_skbmem+0x52/0xa0 key_extract+0x9c/0x2b0 [openvswitch] ovs_flow_key_extract+0x124/0x350 [openvswitch] ovs_vport_receive+0x61/0xd0 [openvswitch] ? kernel_init_free_pages.part.0+0x4a/0x70 ? get_page_from_freelist+0x353/0x540 netdev_port_receive+0xc4/0x180 [openvswitch] ? netdev_port_receive+0x180/0x180 [openvswitch] netdev_frame_hook+0x1f/0x40 [openvswitch] __netif_receive_skb_core.constprop.0+0x23a/0xf00 __netif_receive_skb_list_core+0xfa/0x240 netif_receive_skb_list_internal+0x18e/0x2a0 napi_complete_done+0x7a/0x1c0 bnxt_poll+0x155/0x1c0 [bnxt_en] __napi_poll+0x30/0x180 net_rx_action+0x126/0x280 ? bnxt_msix+0x67/0x80 [bnxt_en] handle_softirqs+0xda/0x2d0 irq_exit_rcu+0x96/0xc0 common_interrupt+0x8e/0xa0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: prevent A-MSDU attacks in mesh networksThis patch is a mitigation to prevent the A-MSDU spoofing vulnerabilityfor mesh networks. The initial update to the IEEE 802.11 standard, inresponse to the FragAttacks, missed this case (CVE-2025-27558). It canbe considered a variant of CVE-2020-24588 but for mesh networks.This patch tries to detect if a standard MSDU was turned into an A-MSDUby an adversary. This is done by parsing a received A-MSDU as a standardMSDU, calculating the length of the Mesh Control header, and seeing ifthe 6 bytes after this header equal the start of an rfc1042 header. Ifequal, this is a strong indication of an ongoing attack attempt.This defense was tested with mac80211_hwsim against a mesh network thatuses an empty Mesh Address Extension field, i.e., when four addressesare used, and when using a 12-byte Mesh Address Extension field, i.e.,when six addresses are used. Functionality of normal MSDUs and A-MSDUswas also tested, and confirmed working, when using both an empty and12-byte Mesh Address Extension field.It was also tested with mac80211_hwsim that A-MSDU attacks in non-meshnetworks keep being detected and prevented.Note that the vulnerability being patched, and the defense beingimplemented, was also discussed in the following paper and in thefollowing IEEE 802.11 presentation:https://papers.mathyvanhoef.com/wisec2025.pdfhttps://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix race with concurrent opens in rename(2)Besides sending the rename request to the server, the rename processalso involves closing any deferred close, waiting for outstanding I/Oto complete as well as marking all existing open handles as deleted toprevent them from deferring closes, which increases the race windowfor potential concurrent opens on the target file.Fix this by unhashing the dentry in advance to prevent any concurrentopens on the target.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: ping in iputils before 20250602 allows a denial of service (application error or incorrect data collection) via a crafted ICMP Echo Reply packet, because of a signed 64-bit integer overflow in timestamp multiplication.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- iputils > 0-0 (version in image is 20221126-150500.3.14.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending unsolicited announcements containing CNAME resource records pointing it to resource records with short TTLs. As soon as they expire avahi-daemon crashes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libavahi-client3 > 0-0 (version in image is 0.8-150400.7.26.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending 2 unsolicited announcements with CNAME resource records 2 seconds apart.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libavahi-client3 > 0-0 (version in image is 0.8-150400.7.26.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Check for the presence of LS_NLA_TYPE_DGID correctlyThe netlink response for RDMA_NL_LS_OP_IP_RESOLVE should always have aLS_NLA_TYPE_DGID attribute, it is invalid if it does not.Use the nl parsing logic properly and call nla_parse_deprecated() to fillthe nlattrs array and then directly index that array to get the data forthe DGID. Just fail if it is NULL.Remove the for loop searching for the nla, and squash the validation andparsing into one function.Fixes an uninitialized read from the stack triggered by userspace if itdoes not provide the DGID to a kernel initiated RDMA_NL_LS_OP_IP_RESOLVEquery. BUG: KMSAN: uninit-value in hex_byte_pack include/linux/hex.h:13 [inline] BUG: KMSAN: uninit-value in ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 hex_byte_pack include/linux/hex.h:13 [inline] ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509 ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633 pointer+0xc09/0x1bd0 lib/vsprintf.c:2542 vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930 vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279 vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426 vprintk_default+0x3f/0x50 kernel/printk/printk.c:2465 vprintk+0x36/0x50 kernel/printk/printk_safe.c:82 _printk+0x17e/0x1b0 kernel/printk/printk.c:2475 ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [inline] ib_nl_handle_ip_res_resp+0x963/0x9d0 drivers/infiniband/core/addr.c:141 rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [inline] rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0xefa/0x11c0 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x333/0x3d0 net/socket.c:729 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2671 __sys_sendmsg+0x1aa/0x300 net/socket.c:2703 __compat_sys_sendmsg net/compat.c:346 [inline] __do_compat_sys_sendmsg net/compat.c:353 [inline] __se_compat_sys_sendmsg net/compat.c:350 [inline] __ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350 ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:3
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timerWhen advancing the target expiration for the guest's APIC timer in periodicmode, set the expiration to "now" if the target expiration is in the past(similar to what is done in update_target_expiration()). Blindly addingthe period to the previous target expiration can result in KVM generatinga practically unbounded number of hrtimer IRQs due to programming anexpired timer over and over. In extreme scenarios, e.g. if userspacepauses/suspends a VM for an extended duration, this can even cause hardlockups in the host.Currently, the bug only affects Intel CPUs when using the hypervisor timer(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,a.k.a. hrtimer, which KVM keeps running even on exits to userspace, theHV timer only runs while the guest is active. As a result, if the vCPUdoes not run for an extended duration, there will be a huge gap betweenthe target expiration and the current time the vCPU resumes running.Because the target expiration is incremented by only one period on eachtimer expiration, this leads to a series of timer expirations occurringrapidly after the vCPU/VM resumes.More critically, when the vCPU first triggers a periodic HV timerexpiration after resuming, advancing the expiration by only one periodwill result in a target expiration in the past. As a result, the deltamay be calculated as a negative value. When the delta is converted intoan absolute value (tscdeadline is an unsigned u64), the resulting valuecan overflow what the HV timer is capable of programming. I.e. the largevalue will exceed the VMX Preemption Timer's maximum bit width ofcpu_preemption_timer_multi + 32, and thus cause KVM to switch from theHV timer to the software timer (hrtimers).After switching to the software timer, periodic timer expiration callbacksmay be executed consecutively within a single clock interrupt handler,because hrtimers honors KVM's request for an expiration in the past andimmediately re-invokes KVM's callback after reprogramming. And becausethe interrupt handler runs with IRQs disabled, restarting KVM's hrtimerover and over until the target expiration is advanced to "now" can resultin a hard lockup.E.g. the following hard lockup was triggered in the host when running aWindows VM (only relevant because it used the APIC timer in periodic mode)after resuming the VM from a long suspend (in the host). NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: apic_timer_fn+0x31/0x50 [kvm] __hrtimer_run_queues+0x100/0x280 hrtimer_interrupt+0x100/0x210 ? ttwu_do_wakeup+0x19/0x160 smp_apic_timer_interrupt+0x6a/0x130 apic_timer_interrupt+0xf/0x20 Moreover, if the suspend duration of the virtual machine is not long enoughto trigger a hard lockup in this scenario, since commit 98c25ead5eda("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVMwill continue using the software timer until the guest reprograms the APICtimer in some way. Since the periodic timer does not require frequent APICtimer register programming, the guest may continue to use the softwaretimer in ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libssh-config > 0-0 (version in image is 0.9.8-150400.3.17.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: replace overzealous BUG_ON in osdmap_apply_incremental()If the osdmap is (maliciously) corrupted such that the incrementalosdmap epoch is different from what is expected, there is no need toBUG. Instead, just declare the incremental osdmap to be invalid.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: return the handler error from mon_handle_auth_done()Currently any error from ceph_auth_handle_reply_done() is propagatedvia finish_auth() but isn't returned from mon_handle_auth_done(). Thisresults in higher layers learning that (despite the monitor consideringus to be successfully authenticated) something went wrong in theauthentication phase and reacting accordingly, but msgr2 still tryingto proceed with establishing the session in the background. In thecase of secure mode this can trigger a WARN in setup_crypto() and laterlead to a NULL pointer dereference inside of prepare_auth_signature().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: cap TX credit to local buffer sizeThe virtio transports derives its TX credit directly from peer_buf_alloc,which is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value.On the host side this means that the amount of data we are willing toqueue for a connection is scaled by a guest-chosen buffer size, ratherthan the host's own vsock configuration. A malicious guest can advertisea large buffer and read slowly, causing the host to allocate acorrespondingly large amount of sk_buff memory.The same thing would happen in the guest with a malicious host, sincevirtio transports share the same code base.Introduce a small helper, virtio_transport_tx_buf_size(), thatreturns min(peer_buf_alloc, buf_alloc), and use it wherever we consumepeer_buf_alloc.This ensures the effective TX window is bounded by both the peer'sadvertised buffer and our own buf_alloc (already clamped tobuffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peercannot force the other to queue more data than allowed by its ownvsock settings.On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with32 guest vsock connections advertising 2 GiB each and reading slowlydrove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system onlyrecovered after killing the QEMU process. That said, if QEMU memory islimited with cgroups, the maximum memory used will be limited.With this patch applied: Before: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB After 32 high-credit connections: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiBOnly ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guestremains responsive.Compatibility with non-virtio transports: - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per socket based on the local vsk->buffer_* values; the remote side cannot enlarge those queues beyond what the local endpoint configured. - Hyper-V's vsock transport uses fixed-size VMBus ring buffers and an MTU bound; there is no peer-controlled credit field comparable to peer_buf_alloc, and the remote endpoint cannot drive in-flight kernel memory above those ring sizes. - The loopback path reuses virtio_transport_common.c, so it naturally follows the same semantics as the virtio transport.This change is limited to virtio_transport_common.c and thus affectsvirtio-vsock, vhost-vsock, and loopback, bringing them in line with the"remote window intersected with local policy" behaviour that VMCI andHyper-V already effectively have.[Stefano: small adjustments after changing the previous patch][Stefano: tweak the commit message]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctlyThe existing allocation of scatterlists in omap_crypto_copy_sg_lists()was allocating an array of scatterlist pointers, not scatterlist objects,resulting in a 4x too small allocation.Use sizeof(*new_sg) to get the correct object size.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: fix UAF in xchk_btree_check_block_ownerWe cannot dereference bs->cur when trying to determine if bs->curaliases bs->sc->sa.{bno,rmap}_cur after the latter has been freed.Fix this by sampling before type before any freeing could happen.The correct temporal ordering was broken when we removed xfs_btnum_t.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQCurrently the code attempts to accept requests regardless of thecommand identifier which may cause multiple requests to be markedas pending (FLAG_DEFER_SETUP) which can cause more thanL2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defercausing an overflow.The spec is quite clear that the same identifier shall not be used onsubsequent requests:'Within each signaling channel a different Identifier shall be usedfor each successive request or indication.'https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355dSo this attempts to check if there are any channels pending with thesame identifier and rejects if any are found.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTEWhen installing an emulated MMIO SPTE, do so *after* dropping/zapping theexisting SPTE (if it's shadow-present). While commit a54aa15c6bda3 wasright about it being impossible to convert a shadow-present SPTE to anMMIO SPTE due to a _guest_ write, it failed to account for writes to guestmemory that are outside the scope of KVM.E.g. if host userspace modifies a shadowed gPTE to switch from a memslotto emulted MMIO and then the guest hits a relevant page fault, KVM willinstall the MMIO SPTE without first zapping the shadow-present SPTE. ------------[ cut here ]------------ is_shadow_present_pte(*sptep) WARNING: arch/x86/kvm/mmu/mmu.c:484 at mark_mmio_spte+0xb2/0xc0 [kvm], CPU#0: vmx_ept_stale_r/4292 Modules linked in: kvm_intel kvm irqbypass CPU: 0 UID: 1000 PID: 4292 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:mark_mmio_spte+0xb2/0xc0 [kvm] Call Trace: mmu_set_spte+0x237/0x440 [kvm] ept_page_fault+0x535/0x7f0 [kvm] kvm_mmu_do_page_fault+0xee/0x1f0 [kvm] kvm_mmu_page_fault+0x8d/0x620 [kvm] vmx_handle_exit+0x18c/0x5a0 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0x730 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x47fa3f ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libavahi-client3 > 0-0 (version in image is 0.8-150400.7.26.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libexpat1 > 0-0 (version in image is 2.7.1-150400.3.37.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virt: tdx-guest: Fix handling of host controlled 'quote' buffer lengthValidate host controlled value `quote_buf->out_len` that determines howmany bytes of the quote are copied out to guest userspace. In TDXenvironments with remote attestation, quotes are not considered private,and can be forwarded to an attestation server.Catch scenarios where the host specifies a response length larger thanthe guest's allocation, or otherwise races modifying the response whilethe guest consumes it.This prevents contents beyond the pages allocated for `quote_buf`(up to TSM_REPORT_OUTBLOB_MAX) from being read out to guest userspace,and possibly forwarded in attestation requests.Recall that some deployments want per-container configs-tsm-reportinterfaces, so the leak may cross container protection boundaries, notjust local root.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_csum: validate nested VLAN headerstcf_csum_act() walks nested VLAN headers directly from skb->data when anskb still carries in-payload VLAN tags. The current code readsvlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes withoutfirst ensuring that the full VLAN header is present in the linear area.If only part of an inner VLAN header is linearized, accessingh_vlan_encapsulated_proto reads past the linear area, and the followingskb_pull(VLAN_HLEN) may violate skb invariants.Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing andpulling each nested VLAN header. If the header still is not fullyavailable, drop the packet through the existing error path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- openssh > 0-0 (version in image is 8.4p1-150300.3.57.1).
-
Description: spdystream is a Go library for multiplexing streams over SPDY connections. In versions 0.5.0 and below, the SPDY/3 frame parser does not validate attacker-controlled counts and lengths before allocating memory. Three allocation paths are affected: the SETTINGS frame entry count, the header count in parseHeaderValueBlock, and individual header field sizes - all read as 32-bit integers and used directly as allocation sizes with no bounds checking. Because SPDY header blocks are zlib-compressed, a small on-the-wire payload can decompress into large attacker-controlled values. A remote peer that can send SPDY frames to a service using spdystream can exhaust process memory and cause an out-of-memory crash with a single crafted control frame. This issue has been fixed in version 0.5.1.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- containerd > 0-0 (version in image is 1.7.29-150000.132.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.56.1).
-
Description: Unknown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.56.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libxml2-2 > 0-0 (version in image is 2.10.3-150500.5.38.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubi: Fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctlHulk Robot reported a KASAN report about use-after-free: ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0x13d/0x160 Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385 [...] Call Trace: klist_dec_and_del+0xa7/0x4a0 klist_put+0xc7/0x1a0 device_del+0x4d4/0xed0 cdev_device_del+0x1a/0x80 ubi_attach_mtd_dev+0x2951/0x34b0 [ubi] ctrl_cdev_ioctl+0x286/0x2f0 [ubi] Allocated by task 1414: device_add+0x60a/0x18b0 cdev_device_add+0x103/0x170 ubi_create_volume+0x1118/0x1a10 [ubi] ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi] Freed by task 1385: cdev_device_del+0x1a/0x80 ubi_remove_volume+0x438/0x6c0 [ubi] ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi] [...] ==================================================================The lock held by ctrl_cdev_ioctl is ubi_devices_mutex, but the lock heldby ubi_cdev_ioctl is ubi->device_mutex. Therefore, the two locks can beconcurrent.ctrl_cdev_ioctl contains two operations: ubi_attach and ubi_detach.ubi_detach is bug-free because it uses reference counting to preventconcurrency. However, uif_init and uif_close in ubi_attach may race withubi_cdev_ioctl.uif_init will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3_______________________|________________________|______________________ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_add_volume // sysfs exist kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume cdev_del // double free cdev_device_delAnd uif_close will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3_______________________|________________________|______________________ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_debugfs_init_dev //error goto out_uif; uif_close kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume // double freeThe cause of this problem is that commit 714fb87e8bc0 make device"available" before it becomes accessible via sysfs. Therefore, weroll back the modification. We will fix the race condition betweenubi device creation and udev by removing ubi_get_device invol_attribute_show and dev_attribute_show.This avoids accessinguninitialized ubi_devices[ubi_num].ubi_get_device is used to prevent devices from being deleted duringsysfs execution. However, now kernfs ensures that devices will notbe deleted before all reference counting are released.The key process is shown in the following stack.device_del device_remove_attrs device_remove_groups sysfs_remove_groups sysfs_remove_group remove_files kernfs_remove_by_name kernfs_remove_by_name_ns __kernfs_remove kernfs_drain
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: Use different devices for resource allocation and DT lookupFollowing by the below discussion, there's the potential UAF issuebetween regulator and mfd.https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/From the analysis of YingliangCPU A |CPU Bmt6370_probe() | devm_mfd_add_devices() | |mt6370_regulator_probe() | regulator_register() | //allocate init_data and add it to devres | regulator_of_get_init_data()i2c_unregister_device() | device_del() | devres_release_all() | // init_data is freed | release_nodes() | | // using init_data causes UAF | regulator_register()It's common to use mfd core to create child device for the regulator.In order to do the DT lookup for init data, the child that registeredthe regulator would pass its parent as the parameter. And this causesinit data resource allocated to its parent, not itself. The issue happenwhen parent device is going to release and regulator core is still doingsome operation of init data constraint for the regulator of child device.To fix it, this patch expand 'regulator_register' API to use thedifferent devices for init data allocation and DT lookup.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add bounds checking in get_max_inline_xattr_value_size()Normally the extended attributes in the inode body would have beenchecked when the inode is first opened, but if someone is writing tothe block device while the file system is mounted, it's possible forthe inode table to get corrupted. Add bounds checking to avoidreading beyond the end of allocated memory if this happens.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: message: mptlan: Fix use after free bug in mptlan_remove() due to race conditionmptlan_probe() calls mpt_register_lan_device() which initializes the&priv->post_buckets_task workqueue. A call tompt_lan_wake_post_buckets_task() will subsequently start the work.During driver unload in mptlan_remove() the following race may occur:CPU0 CPU1 |mpt_lan_post_receive_buckets_work()mptlan_remove() | free_netdev() | kfree(dev); | | | dev->mtu | //useFix this by finishing the work prior to cleaning up in mptlan_remove().[mkp: we really should remove mptlan instead of attempting to fix it]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: A flaw was found in grub2 where the grub_extcmd_dispatcher() function calls grub_arg_list_alloc() to allocate memory for the grub's argument list. However, it fails to check in case the memory allocation fails. Once the allocation fails, a NULL point will be processed by the parse_option() function, leading grub to crash or, in some rare scenarios, corrupt the IVT data.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.65.1).
-
Description: When reading the language .mo file in grub_mofile_open(), grub2 fails to verify an integer overflow when allocating its internal buffer. A crafted .mo file may lead the buffer size calculation to overflow, leading to out-of-bound reads and writes. This flaw allows an attacker to leak sensitive data or overwrite critical data, possibly circumventing secure boot protections.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.65.1).
-
Description: A flaw was found in grub2. The calculation of the translation buffer when reading a language .mo file in grub_gettext_getstr_from_position() may overflow, leading to a Out-of-bound write. This issue can be leveraged by an attacker to overwrite grub2's sensitive heap data, eventually leading to the circumvention of secure boot protections.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.65.1).
-
Description: An integer overflow flaw was found in the BFS file system driver in grub2. When reading a file with an indirect extent map, grub2 fails to validate the number of extent entries to be read. A crafted or corrupted BFS filesystem may cause an integer overflow during the file reading, leading to a heap of bounds read. As a consequence, sensitive data may be leaked, or grub2 will crash.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.65.1).
-
Description: A flaw was found in grub2. When reading tar files, grub2 allocates an internal buffer for the file name. However, it fails to properly verify the allocation against possible integer overflows. It's possible to cause the allocation length to overflow with a crafted tar file, leading to a heap out-of-bounds write. This flaw eventually allows an attacker to circumvent secure boot protections.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.65.1).
-
Description: A flaw was found in grub2. When failing to mount an HFS+ grub, the hfsplus filesystem driver doesn't properly set an ERRNO value. This issue may lead to a NULL pointer access.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.65.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:topology: Keep the cpumask unchanged when printing cpumapDuring fuzz testing, the following warning was discovered: different return values (15 and 11) from vsnprintf("%*pbl ", ...) test:keyward is WARNING in kvasprintf WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130 Call Trace: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmap_print_to_buf+0x89/0x100 core_siblings_list_read+0x7e/0xb0 kernfs_file_read_iter+0x15b/0x270 new_sync_read+0x153/0x260 vfs_read+0x215/0x290 ksys_read+0xb9/0x160 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2The call trace shows that kvasprintf() reported this warning during theprinting of core_siblings_list. kvasprintf() has several steps: (1) First, calculate the length of the resulting formatted string. (2) Allocate a buffer based on the returned length. (3) Then, perform the actual string formatting. (4) Check whether the lengths of the formatted strings returned in steps (1) and (2) are consistent.If the core_cpumask is modified between steps (1) and (3), the lengthsobtained in these two steps may not match. Indeed our test includes cpuhotplugging, which should modify core_cpumask while printing.To fix this issue, cache the cpumask into a temporary variable beforecalling cpumap_print_{list, cpumask}_to_buf(), to keep it unchangedduring the printing process.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: vmclock: Set driver data before its usageIf vmclock_ptp_register() fails during probing, vmclock_remove() iscalled to clean up the ptp clock and misc device.It uses dev_get_drvdata() to access the vmclock state.However the driver data is not yet set at this point.Assign the driver data earlier.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: Don't reference skb after sending to VIOSPreviously, after successfully flushing the xmit buffer to VIOS,the tx_bytes stat was incremented by the length of the skb.It is invalid to access the skb memory after sending the buffer tothe VIOS because, at any point after sending, the VIOS can triggeran interrupt to free this memory. A race between reading skb->lenand freeing the skb is possible (especially during LPM) and willresult in use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic] Read of size 4 at addr c00000024eb48a70 by task hxecom/14495 <...> Call Trace: [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable) [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0 [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8 [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0 [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic] [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358 <...> Freed by task 0: kasan_save_stack+0x34/0x68 kasan_save_track+0x2c/0x50 kasan_save_free_info+0x64/0x108 __kasan_mempool_poison_object+0x148/0x2d4 napi_skb_cache_put+0x5c/0x194 net_tx_action+0x154/0x5b8 handle_softirqs+0x20c/0x60c do_softirq_own_stack+0x6c/0x88 <...> The buggy address belongs to the object at c00000024eb48a00 which belongs to the cache skbuff_head_cache of size 224==================================================================
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:loop: Avoid updating block size under exclusive ownerSyzbot came up with a reproducer where a loop device block size ischanged underneath a mounted filesystem. This causes a mismatch betweenthe block device block size and the block size stored in the superblockcausing confusion in various places such as fs/buffer.c. The particularissue triggered by syzbot was a warning in __getblk_slow() due torequested buffer size not matching block device block size.Fix the problem by getting exclusive hold of the loop device to changeits block size. This fails if somebody (such as filesystem) has alreadyan exclusive ownership of the block device and thus prevents modifyingthe loop device under some exclusive owner which doesn't expect it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: qgroup: fix race between quota disable and quota rescan ioctlThere's a race between a task disabling quotas and another running therescan ioctl that can result in a use-after-free of qgroup records fromthe fs_info->qgroup_tree rbtree.This happens as follows:1) Task A enters btrfs_ioctl_quota_rescan() -> btrfs_qgroup_rescan();2) Task B enters btrfs_quota_disable() and calls btrfs_qgroup_wait_for_completion(), which does nothing because at that point fs_info->qgroup_rescan_running is false (it wasn't set yet by task A);3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups from fs_info->qgroup_tree without taking the lock fs_info->qgroup_lock;4) Task A enters qgroup_rescan_zero_tracking() which starts iterating the fs_info->qgroup_tree tree while holding fs_info->qgroup_lock, but task B is freeing qgroup records from that tree without holding the lock, resulting in a use-after-free.Fix this by taking fs_info->qgroup_lock at btrfs_free_qgroup_config().Also at btrfs_qgroup_rescan() don't start the rescan worker if quotaswere already disabled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: writeback: fix use-after-free in __mark_inode_dirty()An use-after-free issue occurred when __mark_inode_dirty() get thebdi_writeback that was in the progress of switching.CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1......pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __mark_inode_dirty+0x124/0x418lr : __mark_inode_dirty+0x118/0x418sp : ffffffc08c9dbbc0........Call trace: __mark_inode_dirty+0x124/0x418 generic_update_time+0x4c/0x60 file_modified+0xcc/0xd0 ext4_buffered_write_iter+0x58/0x124 ext4_file_write_iter+0x54/0x704 vfs_write+0x1c0/0x308 ksys_write+0x74/0x10c __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x40/0xe4 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x194/0x198Root cause is:systemd-random-seed kworker----------------------------------------------------------------------___mark_inode_dirty inode_switch_wbs_work_fn spin_lock(&inode->i_lock); inode_attach_wb locked_inode_to_wb_and_lock_list get inode->i_wb spin_unlock(&inode->i_lock); spin_lock(&wb->list_lock) spin_lock(&inode->i_lock) inode_io_list_move_locked spin_unlock(&wb->list_lock) spin_unlock(&inode->i_lock) spin_lock(&old_wb->list_lock) inode_do_switch_wbs spin_lock(&inode->i_lock) inode->i_wb = new_wb spin_unlock(&inode->i_lock) spin_unlock(&old_wb->list_lock) wb_put_many(old_wb, nr_switched) cgwb_release old wb released wb_wakeup_delayed() accesses wb, then trigger the use-after-free issueFix this race condition by holding inode spinlock untilwb_wakeup_delayed() finished.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: Set fb_display[i]->mode to NULL when the mode is releasedRecently, we discovered the following issue through syzkaller:BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0Read of size 4 at addr ff11000001b3c69c by task syz.xxx...Call Trace: dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7eBased on experimentation and analysis, during framebuffer unregistration,only the memory of fb_info->modelist is freed, without setting thecorresponding fb_display[i]->mode to NULL for the freed modes. This leadsto UAF issues during subsequent accesses. Here's an example of reproductionsteps:1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1;2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP);3. Switch console from fb to VGA (to allow normal rmmod of the ko);4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[];5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0.Add a check in do_unregister_framebuffer(): if the mode to be freed existsin fb_display[], set the corresponding mode pointer to NULL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-fc: use lock accessing port_state and rport statenvme_fc_unregister_remote removes the remote port on a lport object atany point in time when there is no active association. This races withwith the reconnect logic, because nvme_fc_create_association is nottaking a lock to check the port_state and atomically increase theactive count on the rport.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-fc: avoid scheduling association deletion twiceWhen forcefully shutting down a port via the configfs interface,nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() andthen nvmet_disable_port(). Both functions will eventually schedule allremaining associations for deletion.The current implementation checks whether an association is about to beremoved, but only after the work item has already been scheduled. As aresult, it is possible for the first scheduled work item to free allresources, and then for the same work item to be scheduled again fordeletion.Because the association list is an RCU list, it is not possible to takea lock and remove the list entry directly, so it cannot be looked upagain. Instead, a flag (terminating) must be used to determine whetherthe association is already in the process of being deleted.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: replace BUG_ON with bounds check for map->max_osdOSD indexes come from untrusted network packets. Boundary checks areadded to validate these against map->max_osd.[ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_mr: Fix use-after-free when updating multicast route statsCited commit added a dedicated mutex (instead of RTNL) to protect themulticast route list, so that it will not change while the driverperiodically traverses it in order to update the kernel about multicastroute stats that were queried from the device.One instance of list entry deletion (during route replace) was missedand it can result in a use-after-free [1].Fix by acquiring the mutex before deleting the entry from the list andreleasing it afterwards.[1]BUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]Read of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043CPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full)Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017Workqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum]Call Trace: dump_stack_lvl+0xba/0x110 print_report+0x174/0x4f5 kasan_report+0xdf/0x110 mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30 Allocated by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30Freed by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x43/0x70 kfree+0x14e/0x700 mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_gate: snapshot parameters with RCU on replaceThe gate action can be replaced while the hrtimer callback or dump path iswalking the schedule list.Convert the parameters to an RCU-protected snapshot and swap updates undertcf_lock, freeing the previous snapshot via call_rcu(). When REPLACE omitsthe entry list, preserve the existing schedule so the effective state isunchanged.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Do not skip unrelated mode changes in DSC validationStarting with commit 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation inatomic check"), amdgpu resets the CRTC state mode_changed flag to false whenrecomputing the DSC configuration results in no timing change for a particularstream.However, this is incorrect in scenarios where a change in MST/DSC configurationhappens in the same KMS commit as another (unrelated) mode change. For example,the integrated panel of a laptop may be configured differently (e.g., HDRenabled/disabled) depending on whether external screens are attached. In thiscase, plugging in external DP-MST screens may result in the mode_changed flagbeing dropped incorrectly for the integrated panel if its DSC configurationdid not change during precomputation in pre_validate_dsc().At this point, however, dm_update_crtc_state() has already created new streamsfor CRTCs with DSC-independent mode changes. In turn,amdgpu_dm_commit_streams() will never release the old stream, resulting in amemory leak. amdgpu_dm_atomic_commit_tail() will never acquire a reference tothe new stream either, which manifests as a use-after-free when the stream getsdisabled later on:BUG: KASAN: use-after-free in dc_stream_release+0x25/0x90 [amdgpu]Write of size 4 at addr ffff88813d836524 by task kworker/9:9/29977Workqueue: events drm_mode_rmfb_work_fnCall Trace: dump_stack_lvl+0x6e/0xa0 print_address_description.constprop.0+0x88/0x320 ? dc_stream_release+0x25/0x90 [amdgpu] print_report+0xfc/0x1ff ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x225/0x4e0 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_report+0xe1/0x180 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_check_range+0x125/0x200 dc_stream_release+0x25/0x90 [amdgpu] dc_state_destruct+0x14d/0x5c0 [amdgpu] dc_state_release.part.0+0x4e/0x130 [amdgpu] dm_atomic_destroy_state+0x3f/0x70 [amdgpu] drm_atomic_state_default_clear+0x8ee/0xf30 ? drm_mode_object_put.part.0+0xb1/0x130 __drm_atomic_state_free+0x15c/0x2d0 atomic_remove_fb+0x67e/0x980Since there is no reliable way of figuring out whether a CRTC has unrelatedmode changes pending at the time of DSC validation, remember the value of themode_changed flag from before the point where a CRTC was marked as potentiallyaffected by a change in DSC configuration. Reset the mode_changed flag to thisearlier value instead in pre_validate_dsc().(cherry picked from commit cc7c7121ae082b7b82891baa7280f1ff2608f22b)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/efa: Fix use of completion ctx after freeOn admin queue completion handling, if the admin command completed witherror we print data from the completion context. The issue is that wealready freed the completion context in polling/interrupts handler whichmeans we print data from context in an unknown state (it might bealready used again).Change the admin submission flow so alloc/dealloc of the context will besymmetric and dealloc will be called after any potential use of thecontext.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: fix use-after-free in timeout object destroynft_ct_timeout_obj_destroy() frees the timeout object with kfree()immediately after nf_ct_untimeout(), without waiting for an RCU graceperiod. Concurrent packet processing on other CPUs may still holdRCU-protected references to the timeout object obtained viarcu_dereference() in nf_ct_timeout_data().Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to deferfreeing until after an RCU grace period, matching the approach alreadyused in nfnetlink_cttimeout.c.KASAN report: BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80 Call Trace: nf_conntrack_tcp_packet+0x1381/0x29d0 nf_conntrack_in+0x612/0x8b0 nf_hook_slow+0x70/0x100 __ip_local_out+0x1b2/0x210 tcp_sendmsg_locked+0x722/0x1580 __sys_sendto+0x2d8/0x320 Allocated by task 75: nft_ct_timeout_obj_init+0xf6/0x290 nft_obj_init+0x107/0x1b0 nf_tables_newobj+0x680/0x9c0 nfnetlink_rcv_batch+0xc29/0xe00 Freed by task 26: nft_obj_destroy+0x3f/0xa0 nf_tables_trans_destroy_work+0x51c/0x5c0 process_one_work+0x2c4/0x5a0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: validate connector number in ucsi_notify_common()The connector number extracted from CCI via UCSI_CCI_CONNECTOR() is a7-bit field (0-127) that is used to index into the connector array inucsi_connector_change(). However, the array is only allocated for thenumber of connectors reported by the device (typically 2-4 entries).A malicious or malfunctioning device could report an out-of-rangeconnector number in the CCI, causing an out-of-bounds array access inucsi_connector_change().Add a bounds check in ucsi_notify_common(), the central point where CCIis parsed after arriving from hardware, so that bogus connector numbersare rejected before they propagate further.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In nspawn in systemd 233 through 259 before 260, an escape-to-host action can occur via a crafted optional config file.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libsystemd0 > 0-0 (version in image is 249.17-150400.8.55.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ata: ahci: Match EM_MAX_SLOTS with SATA_PMP_MAX_PORTSUBSAN complains about array-index-out-of-bounds:[ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41[ 1.980709] kernel: index 15 is out of range for type 'ahci_em_priv [8]'[ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsi_eh_8 Not tainted 5.15.0-25-generic #25-Ubuntu[ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010[ 1.980718] kernel: Call Trace:[ 1.980721] kernel: [ 1.980723] kernel: show_stack+0x52/0x58[ 1.980729] kernel: dump_stack_lvl+0x4a/0x5f[ 1.980734] kernel: dump_stack+0x10/0x12[ 1.980736] kernel: ubsan_epilogue+0x9/0x45[ 1.980739] kernel: __ubsan_handle_out_of_bounds.cold+0x44/0x49[ 1.980742] kernel: ahci_qc_issue+0x166/0x170 [libahci][ 1.980748] kernel: ata_qc_issue+0x135/0x240[ 1.980752] kernel: ata_exec_internal_sg+0x2c4/0x580[ 1.980754] kernel: ? vprintk_default+0x1d/0x20[ 1.980759] kernel: ata_exec_internal+0x67/0xa0[ 1.980762] kernel: sata_pmp_read+0x8d/0xc0[ 1.980765] kernel: sata_pmp_read_gscr+0x3c/0x90[ 1.980768] kernel: sata_pmp_attach+0x8b/0x310[ 1.980771] kernel: ata_eh_revalidate_and_attach+0x28c/0x4b0[ 1.980775] kernel: ata_eh_recover+0x6b6/0xb30[ 1.980778] kernel: ? ahci_do_hardreset+0x180/0x180 [libahci][ 1.980783] kernel: ? ahci_stop_engine+0xb0/0xb0 [libahci][ 1.980787] kernel: ? ahci_do_softreset+0x290/0x290 [libahci][ 1.980792] kernel: ? trace_event_raw_event_ata_eh_link_autopsy_qc+0xe0/0xe0[ 1.980795] kernel: sata_pmp_eh_recover.isra.0+0x214/0x560[ 1.980799] kernel: sata_pmp_error_handler+0x23/0x40[ 1.980802] kernel: ahci_error_handler+0x43/0x80 [libahci][ 1.980806] kernel: ata_scsi_port_error_handler+0x2b1/0x600[ 1.980810] kernel: ata_scsi_error+0x9c/0xd0[ 1.980813] kernel: scsi_error_handler+0xa1/0x180[ 1.980817] kernel: ? scsi_unjam_host+0x1c0/0x1c0[ 1.980820] kernel: kthread+0x12a/0x150[ 1.980823] kernel: ? set_kthread_struct+0x50/0x50[ 1.980826] kernel: ret_from_fork+0x22/0x30[ 1.980831] kernel: This happens because sata_pmp_init_links() initialize link->pmp up toSATA_PMP_MAX_PORTS while em_priv is declared as 8 elements array.I can't find the maximum Enclosure Management ports specified in AHCIspec v1.3.1, but "12.2.1 LED message type" states that "Port MultiplierInformation" can utilize 4 bits, which implies it can support up to 16ports. Hence, use SATA_PMP_MAX_PORTS as EM_MAX_SLOTS to resolve theissue.BugLink: https://bugs.launchpad.net/bugs/1970074
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/apic: Don't disable x2APIC if lockedThe APIC supports two modes, legacy APIC (or xAPIC), and Extended APIC(or x2APIC). X2APIC mode is mostly compatible with legacy APIC, butit disables the memory-mapped APIC interface in favor of one that usesMSRs. The APIC mode is controlled by the EXT bit in the APIC MSR.The MMIO/xAPIC interface has some problems, most notably the APIC LEAK[1]. This bug allows an attacker to use the APIC MMIO interface toextract data from the SGX enclave.Introduce support for a new feature that will allow the BIOS to lockthe APIC in x2APIC mode. If the APIC is locked in x2APIC mode and thekernel tries to disable the APIC or revert to legacy APIC mode a GPfault will occur.Introduce support for a new MSR (IA32_XAPIC_DISABLE_STATUS) and handlethe new locked mode when the LEGACY_XAPIC_DISABLED bit is set bypreventing the kernel from trying to disable the x2APIC.On platforms with the IA32_XAPIC_DISABLE_STATUS MSR, if SGX or TDX areenabled the LEGACY_XAPIC_DISABLED will be set by the BIOS. Iflegacy APIC is required, then it SGX and TDX need to be disabled in theBIOS.[1]: https://aepicleak.com/aepicleak.pdf
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6/sit: use DEV_STATS_INC() to avoid data-racessyzbot/KCSAN reported that multiple cpus are updating dev->stats.tx_errorconcurrently.This is because sit tunnels are NETIF_F_LLTX, meaning their ndo_start_xmit()is not protected by a spinlock.While original KCSAN report was about tx path, rx path has the same issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/swap: fix swap_info_struct race between swapoff and get_swap_pages()The si->lock must be held when deleting the si from the available list. Otherwise, another thread can re-add the si to the available list, whichcan lead to memory corruption. The only place we have found where thishappens is in the swapoff path. This case can be described as below:core 0 core 1swapoffdel_from_avail_list(si) waitingtry lock si->lock acquire swap_avail_lock and re-add si into swap_avail_headacquire si->lock but missing si already being added again, and continuingto clear SWP_WRITEOK, etc.It can be easily found that a massive warning messages can be triggeredinside get_swap_pages() by some special cases, for example, we callmadvise(MADV_PAGEOUT) on blocks of touched memory concurrently, meanwhile,run much swapon-swapoff operations (e.g. stress-ng-swap).However, in the worst case, panic can be caused by the above scene. Inswapoff(), the memory used by si could be kept in swap_info[] afterturning off a swap. This means memory corruption will not be causedimmediately until allocated and reset for a new swap in the swapon path. A panic message caused: (with CONFIG_PLIST_DEBUG enabled)------------[ cut here ]------------top: 00000000e58a3003, n: 0000000013e75cda, p: 000000008cd4451aprev: 0000000035b1e58a, n: 000000008cd4451a, p: 000000002150ee8dnext: 000000008cd4451a, n: 000000008cd4451a, p: 000000008cd4451aWARNING: CPU: 21 PID: 1843 at lib/plist.c:60 plist_check_prev_next_node+0x50/0x70Modules linked in: rfkill(E) crct10dif_ce(E)...CPU: 21 PID: 1843 Comm: stress-ng Kdump: ... 5.10.134+Hardware name: Alibaba Cloud ECS, BIOS 0.0.0 02/06/2015pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)pc : plist_check_prev_next_node+0x50/0x70lr : plist_check_prev_next_node+0x50/0x70sp : ffff0018009d3c30x29: ffff0018009d3c40 x28: ffff800011b32a98x27: 0000000000000000 x26: ffff001803908000x25: ffff8000128ea088 x24: ffff800011b32a48x23: 0000000000000028 x22: ffff001800875c00x21: ffff800010f9e520 x20: ffff001800875c00x19: ffff001800fdc6e0 x18: 0000000000000030x17: 0000000000000000 x16: 0000000000000000x15: 0736076307640766 x14: 0730073007380731x13: 0736076307640766 x12: 0730073007380731x11: 000000000004058d x10: 0000000085a85b76x9 : ffff8000101436e4 x8 : ffff800011c8ce08x7 : 0000000000000000 x6 : 0000000000000001x5 : ffff0017df9ed338 x4 : 0000000000000001x3 : ffff8017ce62a000 x2 : ffff0017df9ed340x1 : 0000000000000000 x0 : 0000000000000000Call trace: plist_check_prev_next_node+0x50/0x70 plist_check_head+0x80/0xf0 plist_add+0x28/0x140 add_to_avail_list+0x9c/0xf0 _enable_swap_info+0x78/0xb4 __do_sys_swapon+0x918/0xa10 __arm64_sys_swapon+0x20/0x30 el0_svc_common+0x8c/0x220 do_el0_svc+0x2c/0x90 el0_svc+0x1c/0x30 el0_sync_handler+0xa8/0xb0 el0_sync+0x148/0x180irq event stamp: 2082270Now, si->lock locked before calling 'del_from_avail_list()' to make sureother thread see the si had been deleted and SWP_WRITEOK cleared together,will not reinsert again.This problem exists in versions after stable 5.10.y.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: compress: fix to call f2fs_wait_on_page_writeback() in f2fs_write_raw_pages()BUG_ON() will be triggered when writing files concurrently,because the same page is writtenback multiple times.1597 void folio_end_writeback(struct folio *folio)1598 { ......1618 if (!__folio_end_writeback(folio))1619 BUG(); ......1625 }kernel BUG at mm/filemap.c:1619!Call Trace: f2fs_write_end_io+0x1a0/0x370 blk_update_request+0x6c/0x410 blk_mq_end_request+0x15/0x130 blk_complete_reqs+0x3c/0x50 __do_softirq+0xb8/0x29b ? sort_range+0x20/0x20 run_ksoftirqd+0x19/0x20 smpboot_thread_fn+0x10b/0x1d0 kthread+0xde/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 Below is the concurrency scenario:[Process A] [Process B] [Process C]f2fs_write_raw_pages() - redirty_page_for_writepage() - unlock page() f2fs_do_write_data_page() - lock_page() - clear_page_dirty_for_io() - set_page_writeback() [1st writeback] ..... - unlock page() generic_perform_write() - f2fs_write_begin() - wait_for_stable_page() - f2fs_write_end() - set_page_dirty() - lock_page() - f2fs_do_write_data_page() - set_page_writeback() [2st writeback]This problem was introduced by the previous commit 7377e853967b ("f2fs:compress: fix potential deadlock of compress file"). All pagelocks werereleased in f2fs_write_raw_pages(), but whether the page wasin the writeback state was ignored in the subsequent writing process.Let's fix it by waiting for the page to writeback before writing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/type1: fix cap_migration information leakFix an information leak where an uninitialized hole in structvfio_iommu_type1_info_cap_migration on the stack is exposed to userspace.The definition of struct vfio_iommu_type1_info_cap_migration contains a hole asshown in this pahole(1) output: struct vfio_iommu_type1_info_cap_migration { struct vfio_info_cap_header header; /* 0 8 */ __u32 flags; /* 8 4 */ /* XXX 4 bytes hole, try to pack */ __u64 pgsize_bitmap; /* 16 8 */ __u64 max_dirty_bitmap_size; /* 24 8 */ /* size: 32, cachelines: 1, members: 4 */ /* sum members: 28, holes: 1, sum holes: 4 */ /* last cacheline: 32 bytes */ };The cap_mig variable is filled in without initializing the hole: static int vfio_iommu_migration_build_caps(struct vfio_iommu *iommu, struct vfio_info_cap *caps) { struct vfio_iommu_type1_info_cap_migration cap_mig; cap_mig.header.id = VFIO_IOMMU_TYPE1_INFO_CAP_MIGRATION; cap_mig.header.version = 1; cap_mig.flags = 0; /* support minimum pgsize */ cap_mig.pgsize_bitmap = (size_t)1 << __ffs(iommu->pgsize_bitmap); cap_mig.max_dirty_bitmap_size = DIRTY_BITMAP_SIZE_MAX; return vfio_info_add_capability(caps, &cap_mig.header, sizeof(cap_mig)); }The structure is then copied to a temporary location on the heap. At this pointit's already too late and ioctl(VFIO_IOMMU_GET_INFO) copies it to userspacelater: int vfio_info_add_capability(struct vfio_info_cap *caps, struct vfio_info_cap_header *cap, size_t size) { struct vfio_info_cap_header *header; header = vfio_info_cap_add(caps, size, cap->id, cap->version); if (IS_ERR(header)) return PTR_ERR(header); memcpy(header + 1, cap + 1, size - sizeof(*header)); return 0; }This issue was found by code inspection.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: always release netdev hooks from notifierThis reverts "netfilter: nf_tables: skip netdev events generated on netns removal".The problem is that when a veth device is released, the veth releasecallback will also queue the peer netns device for removal.Its possible that the peer netns is also slated for removal. In thiscase, the device memory is already released before the pre_exit hook ofthe peer netns runs:BUG: KASAN: slab-use-after-free in nf_hook_entry_head+0x1b8/0x1d0Read of size 8 at addr ffff88812c0124f0 by task kworker/u8:1/45Workqueue: netns cleanup_netCall Trace: nf_hook_entry_head+0x1b8/0x1d0 __nf_unregister_net_hook+0x76/0x510 nft_netdev_unregister_hooks+0xa0/0x220 __nft_release_hook+0x184/0x490 nf_tables_pre_exit_net+0x12f/0x1b0 ..Order is:1. First netns is released, veth_dellink() queues peer netns device for removal2. peer netns is queued for removal3. peer netns device is released, unreg event is triggered4. unreg event is ignored because netns is going down5. pre_exit hook calls nft_netdev_unregister_hooks but device memory might be free'd already.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: macb: fix a memory corruption in extended buffer descriptor modeFor quite some time we were chasing a bug which looked like a suddenpermanent failure of networking and mmc on some of our devices.The bug was very sensitive to any software changes and even more toany kernel debug options.Finally we got a setup where the problem was reproducible withCONFIG_DMA_API_DEBUG=y and it revealed the issue with the rx dma:[ 16.992082] ------------[ cut here ]------------[ 16.996779] DMA-API: macb ff0b0000.ethernet: device driver tries to free DMA memory it has not allocated [device address=0x0000000875e3e244] [size=1536 bytes][ 17.011049] WARNING: CPU: 0 PID: 85 at kernel/dma/debug.c:1011 check_unmap+0x6a0/0x900[ 17.018977] Modules linked in: xxxxx[ 17.038823] CPU: 0 PID: 85 Comm: irq/55-8000f000 Not tainted 5.4.0 #28[ 17.045345] Hardware name: xxxxx[ 17.049528] pstate: 60000005 (nZCv daif -PAN -UAO)[ 17.054322] pc : check_unmap+0x6a0/0x900[ 17.058243] lr : check_unmap+0x6a0/0x900[ 17.062163] sp : ffffffc010003c40[ 17.065470] x29: ffffffc010003c40 x28: 000000004000c03c[ 17.070783] x27: ffffffc010da7048 x26: ffffff8878e38800[ 17.076095] x25: ffffff8879d22810 x24: ffffffc010003cc8[ 17.081407] x23: 0000000000000000 x22: ffffffc010a08750[ 17.086719] x21: ffffff8878e3c7c0 x20: ffffffc010acb000[ 17.092032] x19: 0000000875e3e244 x18: 0000000000000010[ 17.097343] x17: 0000000000000000 x16: 0000000000000000[ 17.102647] x15: ffffff8879e4a988 x14: 0720072007200720[ 17.107959] x13: 0720072007200720 x12: 0720072007200720[ 17.113261] x11: 0720072007200720 x10: 0720072007200720[ 17.118565] x9 : 0720072007200720 x8 : 000000000000022d[ 17.123869] x7 : 0000000000000015 x6 : 0000000000000098[ 17.129173] x5 : 0000000000000000 x4 : 0000000000000000[ 17.134475] x3 : 00000000ffffffff x2 : ffffffc010a1d370[ 17.139778] x1 : b420c9d75d27bb00 x0 : 0000000000000000[ 17.145082] Call trace:[ 17.147524] check_unmap+0x6a0/0x900[ 17.151091] debug_dma_unmap_page+0x88/0x90[ 17.155266] gem_rx+0x114/0x2f0[ 17.158396] macb_poll+0x58/0x100[ 17.161705] net_rx_action+0x118/0x400[ 17.165445] __do_softirq+0x138/0x36c[ 17.169100] irq_exit+0x98/0xc0[ 17.172234] __handle_domain_irq+0x64/0xc0[ 17.176320] gic_handle_irq+0x5c/0xc0[ 17.179974] el1_irq+0xb8/0x140[ 17.183109] xiic_process+0x5c/0xe30[ 17.186677] irq_thread_fn+0x28/0x90[ 17.190244] irq_thread+0x208/0x2a0[ 17.193724] kthread+0x130/0x140[ 17.196945] ret_from_fork+0x10/0x20[ 17.200510] ---[ end trace 7240980785f81d6f ]---[ 237.021490] ------------[ cut here ]------------[ 237.026129] DMA-API: exceeded 7 overlapping mappings of cacheline 0x0000000021d79e7b[ 237.033886] WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:499 add_dma_entry+0x214/0x240[ 237.041802] Modules linked in: xxxxx[ 237.061637] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.4.0 #28[ 237.068941] Hardware name: xxxxx[ 237.073116] pstate: 80000085 (Nzcv daIf -PAN -UAO)[ 237.077900] pc : add_dma_entry+0x214/0x240[ 237.081986] lr : add_dma_entry+0x214/0x240[ 237.086072] sp : ffffffc010003c30[ 237.089379] x29: ffffffc010003c30 x28: ffffff8878a0be00[ 237.094683] x27: 0000000000000180 x26: ffffff8878e387c0[ 237.099987] x25: 0000000000000002 x24: 0000000000000000[ 237.105290] x23: 000000000000003b x22: ffffffc010a0fa00[ 237.110594] x21: 0000000021d79e7b x20: ffffffc010abe600[ 237.115897] x19: 00000000ffffffef x18: 0000000000000010[ 237.121201] x17: 0000000000000000 x16: 0000000000000000[ 237.126504] x15: ffffffc010a0fdc8 x14: 0720072007200720[ 237.131807] x13: 0720072007200720 x12: 0720072007200720[ 237.137111] x11: 0720072007200720 x10: 0720072007200720[ 237.142415] x9 : 0720072007200720 x8 : 0000000000000259[ 237.147718] x7 : 0000000000000001 x6 : 0000000000000000[ 237.15302---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm: fix a race condition in retrieve_depsThere's a race condition in the multipath target when retrieve_depsraces with multipath_message calling dm_get_device and dm_put_device.retrieve_deps walks the list of open devices without holding any lockbut multipath may add or remove devices to the list while it isrunning. The end result may be memory corruption or use-after-freememory access.See this description of a UAF with multipath_message():https://listman.redhat.com/archives/dm-devel/2022-October/052373.htmlFix this bug by introducing a new rw semaphore "devices_lock". We grabdevices_lock for read in retrieve_deps and we grab it for write indm_get_device and dm_put_device.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: A race condition was found in the Linux kernel's media/xc4000 device driver in xc4000 xc4000_get_frequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: check smcd_v2_ext_offset when receiving proposal msgWhen receiving proposal msg in server, the field smcd_v2_ext_offset inproposal msg is from the remote client and can not be fully trusted.Once the value of smcd_v2_ext_offset exceed the max value, there hasthe chance to access wrong address, and crash may happen.This patch checks the value of smcd_v2_ext_offset before using it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msgWhen receiving proposal msg in server, the fields v2_ext_offset/eid_cnt/ism_gid_cnt in proposal msg are from the remote clientand can not be fully trusted. Especially the field v2_ext_offset,once exceed the max value, there has the chance to access wrongaddress, and crash may happen.This patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cntbefore using them.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msgWhen receiving proposal msg in server, the field iparea_offsetand the field ipv6_prefixes_cnt in proposal msg are from theremote client and can not be fully trusted. Especially thefield iparea_offset, once exceed the max value, there has thechance to access wrong address, and crash may happen.This patch checks iparea_offset and ipv6_prefixes_cnt before using them.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: validate new SA's prefixlen using SA family when sel.family is unsetThis expands the validation introduced in commit 07bf7908950a ("xfrm:Validate address prefix lengths in the xfrm selector.")syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INETBecause of the AF_UNSPEC selector, verify_newsa_info doesn't putlimits on prefixlen_{s,d}. But then copy_from_user_state setsx->sel.family to usersa.family (AF_INET). Do the same conversion inverify_newsa_info before validating prefixlen_{s,d}, since that's howprefixlen is going to be used later on.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: fix potential out-of-bounds access on the first resumeOut-of-bounds access occurs if the fast device is expanded unexpectedlybefore the first-time resume of the cache table. This happens becauseexpanding the fast device requires reloading the cache table forcache_create to allocate new in-core data structures that fit the newsize, and the check in cache_preresume is not performed during thefirst resume, leading to the issue.Reproduce steps:1. prepare component devices:dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc 262144"dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate.dmsetup create cache --notabledmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192"dmsetup resume cdatadmsetup resume cache3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40:dmsetup suspend cacheKASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8Fix by checking the size change on the first resume.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix out-of-bounds access of directory entriesIn the case of the directory size is greater than or equal tothe cluster size, if start_clu becomes an EOF cluster(an invalidcluster) due to file system corruption, then the directory entrywhere ei->hint_femp.eidx hint is outside the directory, resultingin an out-of-bounds access, which may cause further file systemcorruption.This commit adds a check for start_clu, if it is an invalid cluster,the file or directory will be treated as empty.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ila: serialize calls to nf_register_net_hooks()syzbot found a race in ila_add_mapping() [1]commit 031ae72825ce ("ila: call nf_unregister_net_hooks() sooner")attempted to fix a similar issue.Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.Add a mutex to make sure at most one thread is calling nf_register_net_hooks().[1] BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xc3/0x620 mm/kasan/report.c:489 kasan_report+0xd9/0x110 mm/kasan/report.c:602 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline] ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626 nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269 NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672 __netif_receive_skb+0x1d/0x160 net/core/dev.c:5785 process_backlog+0x443/0x15f0 net/core/dev.c:6117 __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883 napi_poll net/core/dev.c:6952 [inline] net_rx_action+0xa94/0x1010 net/core/dev.c:7074 handle_softirqs+0x213/0x8f0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0x109/0x170 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,changing TLS options in one thread would inadvertently change them globallyand therefore possibly also affect other concurrently setup transfers.Disabling certificate verification for a specific transfer couldunintentionally disable the feature for other threads as well.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- curl > 0-0 (version in image is 8.14.1-150400.5.83.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix double free of TCP_Server_Info::hostnameWhen shutting down the server in cifs_put_tcp_session(), cifsd threadmight be reconnecting to multiple DFS targets before it realizes itshould exit the loop, so @server->hostname can't be freed as long ascifsd thread isn't done. Otherwise the following can happen: RIP: 0010:__slab_free+0x223/0x3c0 Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <0f> 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80 RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246 RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068 RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400 RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000 R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500 R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068 FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000) 000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4: PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __reconnect_target_unlocked+0x3e/0x160 [cifs] ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0xce/0x120 ? __slab_free+0x223/0x3c0 ? do_error_trap+0x65/0x80 ? __slab_free+0x223/0x3c0 ? exc_invalid_op+0x4e/0x70 ? __slab_free+0x223/0x3c0 ? asm_exc_invalid_op+0x16/0x20 ? __slab_free+0x223/0x3c0 ? extract_hostname+0x5c/0xa0 [cifs] ? extract_hostname+0x5c/0xa0 [cifs] ? __kmalloc+0x4b/0x140 __reconnect_target_unlocked+0x3e/0x160 [cifs] reconnect_dfs_server+0x145/0x430 [cifs] cifs_handle_standard+0x1ad/0x1d0 [cifs] cifs_demultiplex_thread+0x592/0x730 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: update channel list in reg notifier instead reg workerCurrently when ath11k gets a new channel list, it will be processedaccording to the following steps:1. update new channel list to cfg80211 and queue reg_work.2. cfg80211 handles new channel list during reg_work.3. update cfg80211's handled channel list to firmware byath11k_reg_update_chan_list().But ath11k will immediately execute step 3 after reg_work is justqueued. Since step 2 is asynchronous, cfg80211 may not have completedhandling the new channel list, which may leading to an out-of-boundswrite error:BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_listCall Trace: ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k] kfree+0x109/0x3a0 ath11k_regd_update+0x1cf/0x350 [ath11k] ath11k_regd_update_work+0x14/0x20 [ath11k] process_one_work+0xe35/0x14c0Should ensure step 2 is completely done before executing step 3. ThusWen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set,cfg80211 will notify ath11k after step 2 is done.So enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 willnotify ath11k after step 2 is done. At this time, there will be noKASAN bug during the execution of the step 3.[1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Avoid race in open_cached_dir with lease breaksA pre-existing valid cfid returned from find_or_create_cached_dir mightrace with a lease break, meaning open_cached_dir doesn't consider itvalid, and thinks it's newly-constructed. This leaks a dentry referenceif the allocation occurs before the queued lease break work runs.Avoid the race by extending holding the cfid_list_lock acrossfind_or_create_cached_dir and when the result is checked.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: add locking for bcm_op runtime updatesThe CAN broadcast manager (CAN BCM) can send a sequence of CAN frames viahrtimer. The content and also the length of the sequence can be changedresp reduced at runtime where the 'currframe' counter is then set to zero.Although this appeared to be a safe operation the updates of 'currframe'can be triggered from user space and hrtimer context in bcm_can_tx().Anderson Nascimento created a proof of concept that triggered a KASANslab-out-of-bounds read access which can be prevented with a spin_lock_bh.At the rework of bcm_can_tx() the 'count' variable has been moved intothe protected section as this variable can be modified from both contextstoo.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/page_alloc: fix race condition in unaccepted memory handlingThe page allocator tracks the number of zones that have unaccepted memoryusing static_branch_enc/dec() and uses that static branch in hot paths todetermine if it needs to deal with unaccepted memory.Borislav and Thomas pointed out that the tracking is racy: operations onstatic_branch are not serialized against adding/removing unaccepted pagesto/from the zone.Sanity checks inside static_branch machinery detects it:WARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0The comment around the WARN() explains the problem: /* * Warn about the '-1' case though; since that means a * decrement is concurrent with a first (0->1) increment. IOW * people are trying to disable something that wasn't yet fully * enabled. This suggests an ordering problem on the user side. */The effect of this static_branch optimization is only visible onmicrobenchmark.Instead of adding more complexity around it, remove it altogether.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio: break and reset virtio devices on device_shutdown()Hongyu reported a hang on kexec in a VM. QEMU reported invalid memoryaccesses during the hang. Invalid read at addr 0x102877002, size 2, region '(null)', reason: rejected Invalid write at addr 0x102877A44, size 2, region '(null)', reason: rejected ...It was traced down to virtio-console. Kexec works fine if virtio-consoleis not in use.The issue is that virtio-console continues to write to the MMIO even afterunderlying virtio-pci device is reset.Additionally, Eric noticed that IOMMUs are reset before devices, ifdevices are not reset on shutdown they continue to poke at guest memoryand get errors from the IOMMU. Some devices get wedged then.The problem can be solved by breaking all virtio devices on virtiobus shutdown, then resetting them.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare()Fix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare():1] If dma_map_sg() fails for areq->dst, the device driver would try to free DMA memory it has not allocated in the first place. To fix this, on the "theend_sgs" error path, call dma unmap only if the corresponding dma map was successful.2] If the dma_map_single() call for the IV fails, the device driver would try to free an invalid DMA memory address on the "theend_iv" path: ------------[ cut here ]------------ DMA-API: sun8i-ce 1904000.crypto: device driver tries to free an invalid DMA memory address WARNING: CPU: 2 PID: 69 at kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90 Modules linked in: skcipher_example(O+) CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: G O 6.15.0-rc3+ #24 PREEMPT Tainted: [O]=OOT_MODULE Hardware name: OrangePi Zero2 (DT) pc : check_unmap+0x123c/0x1b90 lr : check_unmap+0x123c/0x1b90 ... Call trace: check_unmap+0x123c/0x1b90 (P) debug_dma_unmap_page+0xac/0xc0 dma_unmap_page_attrs+0x1f4/0x5fc sun8i_ce_cipher_do_one+0x1bd4/0x1f40 crypto_pump_work+0x334/0x6e0 kthread_worker_fn+0x21c/0x438 kthread+0x374/0x664 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]---To fix this, check for !dma_mapping_error() before callingdma_unmap_single() on the "theend_iv" path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix a race between renames and directory loggingWe have a race between a rename and directory inode logging that if ithappens and we crash/power fail before the rename completes, the next timethe filesystem is mounted, the log replay code will end up deleting thefile that was being renamed.This is best explained following a step by step analysis of an interleavingof steps that lead into this situation.Consider the initial conditions:1) We are at transaction N;2) We have directories A and B created in a past transaction (< N);3) We have inode X corresponding to a file that has 2 hardlinks, one in directory A and the other in directory B, so we'll name them as "A/foo_link1" and "B/foo_link2". Both hard links were persisted in a past transaction (< N);4) We have inode Y corresponding to a file that as a single hard link and is located in directory A, we'll name it as "A/bar". This file was also persisted in a past transaction (< N).The steps leading to a file loss are the following and for all of them weare under transaction N: 1) Link "A/foo_link1" is removed, so inode's X last_unlink_trans field is updated to N, through btrfs_unlink() -> btrfs_record_unlink_dir(); 2) Task A starts a rename for inode Y, with the goal of renaming from "A/bar" to "A/baz", so we enter btrfs_rename(); 3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling btrfs_insert_inode_ref(); 4) Because the rename happens in the same directory, we don't set the last_unlink_trans field of directoty A's inode to the current transaction id, that is, we don't cal btrfs_record_unlink_dir(); 5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode() (actually the dir index item is added as a delayed item, but the effect is the same); 6) Now before task A adds the new entry "A/baz" to directory A by calling btrfs_add_link(), another task, task B is logging inode X; 7) Task B starts a fsync of inode X and after logging inode X, at btrfs_log_inode_parent() it calls btrfs_log_all_parents(), since inode X has a last_unlink_trans value of N, set at in step 1; 8) At btrfs_log_all_parents() we search for all parent directories of inode X using the commit root, so we find directories A and B and log them. Bu when logging direct A, we don't have a dir index item for inode Y anymore, neither the old name "A/bar" nor for the new name "A/baz" since the rename has deleted the old name but has not yet inserted the new name - task A hasn't called yet btrfs_add_link() to do that. Note that logging directory A doesn't fallback to a transaction commit because its last_unlink_trans has a lower value than the current transaction's id (see step 4); 9) Task B finishes logging directories A and B and gets back to btrfs_sync_file() where it calls btrfs_sync_log() to persist the log tree;10) Task B successfully persisted the log tree, btrfs_sync_log() completed with success, and a power failure happened. We have a log tree without any directory entry for inode Y, so the log replay code deletes the entry for inode Y, name "A/bar", from the subvolume tree since it doesn't exist in the log tree and the log tree is authorative for its index (we logged a BTRFS_DIR_LOG_INDEX_KEY item that covers the index range for the dentry that corresponds to "A/bar"). Since there's no other hard link for inode Y and the log replay code deletes the name "A/bar", the file is lost.The issue wouldn't happen if task B synced the log only after task Acalled btrfs_log_new_name(), which would update the log with the new namefor inode Y ("A/bar").Fix this by pinning the log root during renames before removing the olddirectory entry, and unpinning af---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()The hfsplus_bnode_read() method can trigger the issue:[ 174.852007][ T9784] ==================================================================[ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360[ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784[ 174.854059][ T9784][ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)[ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 174.854286][ T9784] Call Trace:[ 174.854289][ T9784] [ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0[ 174.854305][ T9784] print_report+0xd0/0x660[ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610[ 174.854323][ T9784] ? __phys_addr+0xe8/0x180[ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360[ 174.854337][ T9784] kasan_report+0xc6/0x100[ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360[ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360[ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380[ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10[ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0[ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310[ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40[ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0[ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0[ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10[ 174.854427][ T9784] ? __pfx___hfsplus_delete_attr+0x10/0x10[ 174.854436][ T9784] ? __asan_memset+0x23/0x50[ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320[ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10[ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0[ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40[ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0[ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10[ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0[ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10[ 174.854525][ T9784] ? down_write+0x148/0x200[ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10[ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0[ 174.854549][ T9784] do_unlinkat+0x490/0x670[ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10[ 174.854565][ T9784] ? __might_fault+0xbc/0x130[ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550[ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110[ 174.854592][ T9784] do_syscall_64+0xc9/0x480[ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167[ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08[ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057[ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167[ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50[ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40[ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0[ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000[ 174.854658][ T9784] [ 174.854661][ T9784][ 174.879281][ T9784] Allocated by task 9784:[ 174.879664][ T9784] kasan_save_stack+0x20/0x40[ 174.880082][ T9784] kasan_save_track+0x14/0x30[ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0[ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550[ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890[ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10[ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520[ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: nfc: nci: Add parameter validation for packet dataSyzbot reported an uninitialized value bug in nci_init_req, which wasintroduced by commit 5aca7966d2a7 ("Merge tag'perf-tools-fixes-for-v6.17-2025-09-16' ofgit://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools").This bug arises due to very limited and poor input validationthat was done at nic_valid_size(). This validation onlyvalidates the skb->len (directly reflects size provided at theuserspace interface) with the length provided in the bufferitself (interpreted as NCI_HEADER). This leads to the processingof memory content at the address assuming the correct layoutper what opcode requires there. This leads to the accesses tobuffer of `skb_buff->data` which is not assigned anything yet.Following the same silent drop of packets of invalid sizes at`nic_valid_size()`, add validation of the data in the respectivehandlers and return error values in case of failure. Releasethe skb if error values are returned from handlers in`nci_nft_packet` and effectively do a silent dropPossible TODO: because we silently drop the packets, thecall to `nci_request` will be waiting for completion of requestand will face timeouts. These timeouts can get excessively loggedin the dmesg. A proper handling of them may require to export`nci_request_cancel` (or propagate error handling from thenft packets handlers).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: parse_dfs_referrals: prevent oob on malformed inputMalicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS- reply smaller than sizeof(struct get_dfs_referral_rsp)- reply with number of referrals smaller than NumberOfReferrals in theheaderProcessing of such replies will cause oob.Return -EINVAL error on such replies to prevent oob-s.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: ISO: Fix possible UAF on iso_conn_freeThis attempt to fix similar issue to sco_conn_free where if theconn->sk is not set to NULL may lead to UAF on iso_conn_free.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().get_netdev_for_sock() is called during setsockopt(),so not under RCU.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dst_dev_rcu().Note that the only ->ndo_sk_get_lower_dev() user isbond_sk_get_lower_dev(), which uses RCU.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU in ip6_output()Use RCU in ip6_output() in order to use dst_dev_rcu() to preventpossible UAF.We can remove rcu_read_lock()/rcu_read_unlock() pairsfrom ip6_finish_output2().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match().smc_clc_prfx_match() is called from smc_listen_work() andnot under RCU nor RTNL.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dst_dev_rcu().Note that the returned value of smc_clc_prfx_match() is notused in the caller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: use dst_dev_rcu() in sk_setup_caps()Use RCU to protect accesses to dst->dev from sk_setup_caps()and sk_dst_gso_max_size().Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),and ip_dst_mtu_maybe_forward().ip4_dst_hoplimit() can use dst_dev_net_rcu().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loopThe cleanup loop was starting at the wrong array index, causingout-of-bounds access.Start the loop at the correct index for zero-indexed arrays to preventaccessing memory beyond the allocated array bounds.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: video: Fix use-after-free in acpi_video_switch_brightness()The switch_brightness_work delayed work accesses device->brightnessand device->backlight, freed by acpi_video_dev_unregister_backlight()during device removal.If the work executes after acpi_video_bus_unregister_backlight()frees these resources, it causes a use-after-free whenacpi_video_switch_brightness() dereferences device->brightness ordevice->backlight.Fix this by calling cancel_delayed_work_sync() for each device'sswitch_brightness_work in acpi_video_bus_remove_notify_handler()after removing the notify handler that queues the work. This ensuresthe work completes before the memory is freed.[ rjw: Changelog edit ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: use dst_dev_rcu() in tcp_fastopen_active_disable_ofo_check()Use RCU to avoid a pair of atomic operations and a potentialUAF on dst_dev()->flags.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsingThe Supported Rates IE length from an incoming Association Request framewas used directly as the memcpy() length when copying into a fixed-size16-byte stack buffer (supportRate). A malicious station can advertise anIE length larger than 16 bytes, causing a stack buffer overflow.Clamp ie_len to the buffer size before copying the Supported Rates IE,and correct the bounds check when merging Extended Supported Rates toprevent a second potential overflow.This prevents kernel stack corruption triggered by malformed associationrequests.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: refresh inline data size before write operationsThe cached ei->i_inline_size can become stale between the initial sizecheck and when ext4_update_inline_data()/ext4_create_inline_data() useit. Although ext4_get_max_inline_size() reads the correct value at thetime of the check, concurrent xattr operations can modify i_inline_sizebefore ext4_write_lock_xattr() is acquired.This causes ext4_update_inline_data() and ext4_create_inline_data() towork with stale capacity values, leading to a BUG_ON() crash inext4_write_inline_data(): kernel BUG at fs/ext4/inline.c:1331! BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);The race window:1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)2. Size check passes for 50-byte write3. [Another thread adds xattr, i_inline_size changes to 40]4. ext4_write_lock_xattr() acquires lock5. ext4_update_inline_data() uses stale i_inline_size = 606. Attempts to write 50 bytes but only 40 bytes actually available7. BUG_ON() triggersFix this by recalculating i_inline_size via ext4_find_inline_data_nolock()immediately after acquiring xattr_sem. This ensures ext4_update_inline_data()and ext4_create_inline_data() work with current values that are protectedfrom concurrent modifications.This is similar to commit a54c4613dac1 ("ext4: fix race writing to aninline_data file while its xattrs are changing") which fixed i_inline_offstaleness. This patch addresses the related i_inline_size staleness issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iomap: adjust read range correctly for non-block-aligned positionsiomap_adjust_read_range() assumes that the position and length passed inare block-aligned. This is not always the case however, as shown in thesyzbot generated case for erofs. This causes too many bytes to beskipped for uptodate blocks, which results in returning the incorrectposition and length to read in. If all the blocks are uptodate, thisunderflows length and returns a position beyond the folio.Fix the calculation to also take into account the block offset whencalculating how many bytes can be skipped for uptodate blocks.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uacce: implement mremap in uacce_vm_ops to return -EPERMThe current uacce_vm_ops does not support the mremap operation ofvm_operations_struct. Implement .mremap to return -EPERM to remindusers.The reason we need to explicitly disable mremap is that when thedriver does not implement .mremap, it uses the default mremapmethod. This could lead to a risk scenario:An application might first mmap address p1, then mremap to p2,followed by munmap(p1), and finally munmap(p2). Since the defaultmremap copies the original vma's vm_private_data (i.e., q) to thenew vma, both munmap operations would trigger vma_close, causingq->qfr to be freed twice(qfr will be set to null here, so repeatedrelease is ok).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: scarlett2: Fix buffer overflow in config retrievalThe scarlett2_usb_get_config() function has a logic error in theendianness conversion code that can cause buffer overflows whencount > 1.The code checks `if (size == 2)` where `size` is the total buffer size inbytes, then loops `count` times treating each element as u16 (2 bytes).This causes the loop to access `count * 2` bytes when the buffer onlyhas `size` bytes allocated.Fix by checking the element size (config_item->size) instead of thetotal buffer size. This ensures the endianness conversion matches theactual element type.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: Fix stats report corruption on queue count changeThe driver and the NIC share a region in memory for stats reporting.The NIC calculates its offset into this region based on the total sizeof the stats region and the size of the NIC's stats.When the number of queues is changed, the driver's stats region isresized. If the queue count is increased, the NIC can write pastthe end of the allocated stats region, causing memory corruption.If the queue count is decreased, there is a gap between the driverand NIC stats, leading to incorrect stats reporting.This change fixes the issue by allocating stats region with maximumsize, and the offset calculation for NIC stats is changed to matchwith the calculation of the NIC.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- grub2 > 0-0 (version in image is 2.06-150500.29.65.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_runIn mtk_jpeg_probe, &jpeg->job_timeout_work is bound withmtk_jpeg_job_timeout_work.In mtk_jpeg_dec_device_run, if error happens inmtk_jpeg_set_dec_dst, it will finally start the worker whilemark the job as finished by invoking v4l2_m2m_job_finish.There are two methods to trigger the bug. If we remove themodule, it which will call mtk_jpeg_remove to make cleanup.The possible sequence is as follows, which will cause ause-after-free bug.CPU0 CPU1mtk_jpeg_dec_... | start worker | |mtk_jpeg_job_timeout_workmtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //useIf we close the file descriptor, which will call mtk_jpeg_release,it will have a similar sequence.Fix this bug by starting timeout worker only if started jpegdec workersuccessfully. Then v4l2_m2m_job_finish will only be called ineither mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:lib: cpu_rmap: Avoid use after free on rmap->obj array entriesWhen calling irq_set_affinity_notifier() with NULL at the notifyargument, it will cause freeing of the glue pointer in thecorresponding array entry but will leave the pointer in the array. Asubsequent call to free_irq_cpu_rmap() will try to free this entry againleading to possible use after free.Fix that by setting NULL to the array entry and checking that we havenon-zero at the array entry when iterating over the array infree_irq_cpu_rmap().The current code does not suffer from this since there are no caseswhere irq_set_affinity_notifier(irq, NULL) (note the NULL passed for thenotify arg) is called, followed by a call to free_irq_cpu_rmap() so wedon't hit and issue. Subsequent patches in this series excersize thisflow, hence the required fix.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix an uninit variable access bug in __ip6_make_skb()Syzbot reported a bug as following:=====================================================BUG: KMSAN: uninit-value in arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline]BUG: KMSAN: uninit-value in arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline]BUG: KMSAN: uninit-value in atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline]BUG: KMSAN: uninit-value in __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956 arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline] arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline] atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline] __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956 ip6_finish_skb include/net/ipv6.h:1122 [inline] ip6_push_pending_frames+0x10e/0x550 net/ipv6/ip6_output.c:1987 rawv6_push_pending_frames+0xb12/0xb90 net/ipv6/raw.c:579 rawv6_sendmsg+0x297e/0x2e60 net/ipv6/raw.c:922 inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530 __sys_sendmsg net/socket.c:2559 [inline] __do_sys_sendmsg net/socket.c:2568 [inline] __se_sys_sendmsg net/socket.c:2566 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988 kmalloc_reserve net/core/skbuff.c:492 [inline] __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565 alloc_skb include/linux/skbuff.h:1270 [inline] __ip6_append_data+0x51c1/0x6bb0 net/ipv6/ip6_output.c:1684 ip6_append_data+0x411/0x580 net/ipv6/ip6_output.c:1854 rawv6_sendmsg+0x2882/0x2e60 net/ipv6/raw.c:915 inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530 __sys_sendmsg net/socket.c:2559 [inline] __do_sys_sendmsg net/socket.c:2568 [inline] __se_sys_sendmsg net/socket.c:2566 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdIt is because icmp6hdr does not in skb linear region under the scenarioof SOCK_RAW socket. Access icmp6_hdr(skb)->icmp6_type directly willtrigger the uninit variable access bug.Use a local variable icmp6_type to carry the correct value in differentscenarios.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Tear down vGIC on failed vCPU creationIf kvm_arch_vcpu_create() fails to share the vCPU page with thehypervisor, we propagate the error back to the ioctl but leave thevGIC vCPU data initialised. Note only does this leak the correspondingmemory when the vCPU is destroyed but it can also lead to use-after-freeif the redistributor device handling tries to walk into the vCPU.Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that thevGIC vCPU structures are destroyed on error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: Perl threads have a working directory race condition where file operations may target unintended paths.If a directory handle is open at thread creation, the process-wide current working directory is temporarily changed in order to clone that handle for the new thread, which is visible from any third (or more) thread already running. This may lead to unintended operations such as loading code or accessing files from unexpected locations, which a local attacker may be able to exploit.The bug was introduced in commit 11a11ecf4bea72b17d250cfb43c897be1341861e and released in Perl version 5.13.6
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- perl > 0-0 (version in image is 5.26.1-150300.17.20.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: greybus: audio_helper: remove unused and wrong debugfs usageIn the greybus audio_helper code, the debugfs file for the dapm has thepotential to be removed and memory will be leaked. There is also thevery real potential for this code to remove ALL debugfs entries from thesystem, and it seems like this is what will really happen if this codeever runs. This all is very wrong as the greybus audio driver did notcreate this debugfs file, the sound core did and controls the lifespanof it.So remove all of the debugfs logic from the audio_helper code as there'sno way it could be correct. If this really is needed, it can come backwith a fixup for the incorrect usage of the debugfs_lookup() call whichis what caused this to be noticed at all.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: az6007: Fix null-ptr-deref in az6007_i2c_xfer()In az6007_i2c_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach az6007_i2c_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_fq: fix integer overflow of "credit"if sch_fq is configured with "initial quantum" having values greater thanINT_MAX, the first assignment of "credit" does signed integer overflow toa very negative value.In this situation, the syzkaller script provided by Cristoph triggers theCPU soft-lockup warning even with few sockets. It's not an infinite loop,but "credit" wasn't probably meant to be minus 2Gb for each new flow.Capping "initial quantum" to INT_MAX proved to fix the issue.v2: validation of "initial quantum" is done in fq_policy, instead of open coding in fq_change() _ suggested by Jakub Kicinski
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: fix wrong ct->timeout value(struct nf_conn)->timeout is an interval before the conntrackconfirmed. After confirmed, it becomes a timestamp.It is observed that timeout of an unconfirmed conntrack:- Set by calling ctnetlink_change_timeout(). As a result, `nfct_time_stamp` was wrongly added to `ct->timeout` twice.- Get by calling ctnetlink_dump_timeout(). As a result, `nfct_time_stamp` was wrongly subtracted.Call Trace: dump_stack_lvl ctnetlink_dump_timeout __ctnetlink_glue_build ctnetlink_glue_build __nfqnl_enqueue_packet nf_queue nf_hook_slow ip_mc_output ? __pfx_ip_finish_output ip_send_skb ? __pfx_dst_output udp_send_skb udp_sendmsg ? __pfx_ip_generic_getfrag sock_sendmsgSeparate the 2 cases in:- Setting `ct->timeout` in __nf_ct_set_timeout().- Getting `ct->timeout` in ctnetlink_dump_timeout().Pablo appends:Update ctnetlink to set up the timeout _after_ the IPS_CONFIRMED flag isset on, otherwise conntrack creation via ctnetlink breaks.Note that the problem described in this patch occurs since theintroduction of the nfnetlink_queue conntrack support, select asufficiently old Fixes: tag for -stable kernel to pick up this fix.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to check readonly condition correctlyWith below case, it can mount multi-device image w/ rw option, howeverone of secondary device is set as ro, later update will cause panic, solet's introduce f2fs_dev_is_readonly(), and check multi-devices rw statusin f2fs_remount() w/ it in order to avoid such inconsistent mount status.mkfs.f2fs -c /dev/zram1 /dev/zram0 -fblockdev --setro /dev/zram1mount -t f2fs dev/zram0 /mnt/f2fsmount: /mnt/f2fs: WARNING: source write-protected, mounted read-only.mount -t f2fs -o remount,rw mnt/f2fsdd if=/dev/zero of=/mnt/f2fs/file bs=1M count=8192kernel BUG at fs/f2fs/inline.c:258!RIP: 0010:f2fs_write_inline_data+0x23e/0x2d0 [f2fs]Call Trace: f2fs_write_single_data_page+0x26b/0x9f0 [f2fs] f2fs_write_cache_pages+0x389/0xa60 [f2fs] __f2fs_write_data_pages+0x26b/0x2d0 [f2fs] f2fs_write_data_pages+0x2e/0x40 [f2fs] do_writepages+0xd3/0x1b0 __writeback_single_inode+0x5b/0x420 writeback_sb_inodes+0x236/0x5a0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x2a3/0x490 wb_do_writeback+0x2b2/0x330 wb_workfn+0x6a/0x260 process_one_work+0x270/0x5e0 worker_thread+0x52/0x3e0 kthread+0xf4/0x120 ret_from_fork+0x29/0x50
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:m68k: Only force 030 bus error if PC not in exception table__get_kernel_nofault() does copy data in supervisor mode whenforcing a task backtrace log through /proc/sysrq_trigger.This is expected cause a bus error exception on e.g. NULLpointer dereferencing when logging a kernel task has noworkqueue associated. This bus error ought to be ignored.Our 030 bus error handler is ill equipped to deal with this:Whenever ssw indicates a kernel mode access on a data fault,we don't even attempt to handle the fault and instead alwayssend a SEGV signal (or panic). As a result, the checkfor exception handling at the fault PC (buried insend_sig_fault() which gets called from do_page_fault()eventually) is never used.In contrast, both 040 and 060 access error handlers do notcare whether a fault happened on supervisor mode access,and will call do_page_fault() on those, ultimately honoringthe exception table.Add a check in bus_error030 to call do_page_fault() in casewe do have an entry for the fault PC in our exception table.I had attempted a fix for this earlier in 2019 that did relyon testing pagefault_disabled() (see link below) to achievethe same thing, but this patch should be more generic.Tested on 030 Atari Falcon.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soundwire: bus: Fix unbalanced pm_runtime_put() causing usage count underflowThis reverts commit443a98e649b4 ("soundwire: bus: use pm_runtime_resume_and_get()")Change calls to pm_runtime_resume_and_get() back to pm_runtime_get_sync().This fixes a usage count underrun caused by doing a pm_runtime_put() eventhough pm_runtime_resume_and_get() returned an error.The three affected functions ignore -EACCES error from trying to getpm_runtime, and carry on, including a put at the end of the function.But pm_runtime_resume_and_get() does not increment the usage count if itreturns an error. So in the -EACCES case you must not callpm_runtime_put().The documentation for pm_runtime_get_sync() says: "Consider using pm_runtime_resume_and_get() ... as this is likely to result in cleaner code."In this case I don't think it results in cleaner code because thepm_runtime_put() at the end of the function would have to be conditional onthe return value from pm_runtime_resume_and_get() at the top of thefunction.pm_runtime_get_sync() doesn't have this problem because it alwaysincrements the count, so always needs a put. The code can just flow throughand do the pm_runtime_put() unconditionally.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:samples/bpf: Fix buffer overflow in tcp_baserttUsing sizeof(nv) or strlen(nv)+1 is correct.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:refscale: Fix uninitalized use of wait_queue_head_tRunning the refscale test occasionally crashes the kernel with thefollowing error:[ 8569.952896] BUG: unable to handle page fault for address: ffffffffffffffe8[ 8569.952900] #PF: supervisor read access in kernel mode[ 8569.952902] #PF: error_code(0x0000) - not-present page[ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0[ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI[ 8569.952916] Hardware name: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021[ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190 :[ 8569.952940] Call Trace:[ 8569.952941] [ 8569.952944] ref_scale_reader+0x380/0x4a0 [refscale][ 8569.952959] kthread+0x10e/0x130[ 8569.952966] ret_from_fork+0x1f/0x30[ 8569.952973] The likely cause is that init_waitqueue_head() is called after the call tothe torture_create_kthread() function that creates the ref_scale_readerkthread. Although this init_waitqueue_head() call will very likelycomplete before this kthread is created and starts running, it ispossible that the calling kthread will be delayed between the calls totorture_create_kthread() and init_waitqueue_head(). In this case, thenew kthread will use the waitqueue head before it is properly initialized,which is not good for the kernel's health and well-being.The above crash happened here: static inline void __add_wait_queue(...) { : if (!(wq->flags & WQ_FLAG_PRIORITY)) <=== Crash hereThe offset of flags from list_head entry in wait_queue_entry is-0x18. If reader_tasks[i].wq.head.next is NULL as allocated reader_taskstructure is zero initialized, the instruction will try to access address0xffffffffffffffe8, which is exactly the fault address listed above.This commit therefore invokes init_waitqueue_head() before creatingthe kthread.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpiolib: cdev: fix uninitialised kfifoIf a line is requested with debounce, and that results in debouncingin software, and the line is subsequently reconfigured to enable edgedetection then the allocation of the kfifo to contain edge events isoverlooked. This results in events being written to and read from anuninitialised kfifo. Read events are returned to userspace.Initialise the kfifo in the case where the software debounce isalready active.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check validity of link->type in bpf_link_show_fdinfo()If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessingbpf_link_type_strs[link->type] may result in an out-of-bounds access.To spot such missed invocations early in the future, checking thevalidity of link->type in bpf_link_show_fdinfo() and emitting a warningwhen such invocations are missed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: Fix uninitialized value issue in from_kuid and from_kgidocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid ina trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set.Initialize all fields of newattrs to avoid uninitialized variables, bychecking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:svcrdma: Address an integer overflowDan Carpenter reports:> Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data> structure") from Jun 22, 2020 (linux-next), leads to the following> Smatch static checker warning:>> net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk()> warn: potential user controlled sizeof overflow 'segcount * 4 * 4'>> net/sunrpc/xprtrdma/svc_rdma_recvfrom.c> 488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt *rctxt)> 489 {> 490 u32 segcount;> 491 __be32 *p;> 492> 493 if (xdr_stream_decode_u32(&rctxt->rc_stream, &segcount))> ^^^^^^^^>> 494 return false;> 495> 496 /* A bogus segcount causes this buffer overflow check to fail. */> 497 p = xdr_inline_decode(&rctxt->rc_stream,> --> 498 segcount * rpcrdma_segment_maxsz * sizeof(*p));>>> segcount is an untrusted u32. On 32bit systems anything >= SIZE_MAX / 16 will> have an integer overflow and some those values will be accepted by> xdr_inline_decode().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix uninitialized value in ocfs2_file_read_iter()Syzbot has reported the following KMSAN splat:BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80 ocfs2_file_read_iter+0x9a4/0xf80 __io_read+0x8d4/0x20f0 io_read+0x3e/0xf0 io_issue_sqe+0x42b/0x22c0 io_wq_submit_work+0xaf9/0xdc0 io_worker_handle_work+0xd13/0x2110 io_wq_worker+0x447/0x1410 ret_from_fork+0x6f/0x90 ret_from_fork_asm+0x1a/0x30Uninit was created at: __alloc_pages_noprof+0x9a7/0xe00 alloc_pages_mpol_noprof+0x299/0x990 alloc_pages_noprof+0x1bf/0x1e0 allocate_slab+0x33a/0x1250 ___slab_alloc+0x12ef/0x35e0 kmem_cache_alloc_bulk_noprof+0x486/0x1330 __io_alloc_req_refill+0x84/0x560 io_submit_sqes+0x172f/0x2f30 __se_sys_io_uring_enter+0x406/0x41c0 __x64_sys_io_uring_enter+0x11f/0x1a0 x64_sys_call+0x2b54/0x3ba0 do_syscall_64+0xcd/0x1e0 entry_SYSCALL_64_after_hwframe+0x77/0x7fSince an instance of 'struct kiocb' may be passed from the block layerwith 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()'and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()This loop is supposed to break if the frequency returned fromclk_round_rate() is the same as on the previous iteration. However,that check doesn't make sense on the first iteration through the loop.It leads to reading before the start of these->clk_perf_tbl[] array.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/bluefield: Fix potential integer overflowThe 64-bit argument for the "get DIMM info" SMC call consists of mem_ctrl_idxleft-shifted 16 bits and OR-ed with DIMM index. With mem_ctrl_idx defined as32-bits wide the left-shift operation truncates the upper 16 bits ofinformation during the calculation of the SMC argument.The mem_ctrl_idx stack variable must be defined as 64-bits wide to prevent anypotential integer overflow, i.e. loss of data from upper 16 bits.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: lan78xx: Fix double free issue with interrupt buffer allocationIn lan78xx_probe(), the buffer `buf` was being freed twice: onceimplicitly through `usb_free_urb(dev->urb_intr)` with the`URB_FREE_BUFFER` flag and again explicitly by `kfree(buf)`. This causeda double free issue.To resolve this, reordered `kmalloc()` and `usb_alloc_urb()` calls tosimplify the initialization sequence and removed the redundant`kfree(buf)`. Now, `buf` is allocated after `usb_alloc_urb()`, ensuringit is correctly managed by `usb_fill_int_urb()` and freed by`usb_free_urb()` as intended.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_regSyzbot reports [1] an uninitialized value issue found by KMSAN indib3000_read_reg().Local u8 rb[2] is used in i2c_transfer() as a read buffer; in casethat call fails, the buffer may end up with some undefined values.Since no elaborate error handling is expected in dib3000_write_reg(),simply zero out rb buffer to mitigate the problem.[1] Syzkaller reportdvb-usb: bulk message failed: -22 (6/0)=====================================================BUG: KMSAN: uninit-value in dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dibusb_dib3000mb_frontend_attach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31 dvb_usb_adapter_frontend_init+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline] dvb_usb_device_init+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310 dibusb_probe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110...Local variable rb created at: dib3000_read_reg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54 dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix mbss changed flags corruption on 32 bit systemsOn 32-bit systems, the size of an unsigned long is 4 bytes,while a u64 is 8 bytes. Therefore, when usingor_each_set_bit(bit, &bits, sizeof(changed) * BITS_PER_BYTE),the code is incorrectly searching for a bit in a 32-bitvariable that is expected to be 64 bits in size,leading to incorrect bit finding.Solution: Ensure that the size of the bits variable is correctlyadjusted for each architecture. Call Trace: ? show_regs+0x54/0x58 ? __warn+0x6b/0xd4 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? report_bug+0x113/0x150 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x44 ? exc_invalid_op+0x18/0x50 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? ieee80211_mesh_work+0xff/0x260 [mac80211] ? cfg80211_wiphy_work+0x72/0x98 [cfg80211] ? process_one_work+0xf1/0x1fc ? worker_thread+0x2c0/0x3b4 ? kthread+0xc7/0xf0 ? mod_delayed_work_on+0x4c/0x4c ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork+0x24/0x38 ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork_asm+0xf/0x14 ? entry_INT80_32+0xf0/0xf0[restore no-op path for no changes]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor modeath11k_hal_srng_* should be used with srng->lock to protect srng data.For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(),they use ath11k_hal_srng_* for many times but never call srng->lock.So when running (full) monitor mode, warning will occur:RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k] ? idr_alloc_u32+0x97/0xd0 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k] ath11k_dp_service_srng+0x289/0x5a0 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k] __napi_poll+0x30/0x1f0 net_rx_action+0x198/0x320 __do_softirq+0xdd/0x319So add srng->lock for them to avoid such warnings.Inorder to fetch the srng->lock, should change srng's definition from'void' to 'struct hal_srng'. And initialize them elsewhere to preventone line of code from being too long. This is consistent with other ringprocess functions, such as ath11k_dp_process_rx().Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: A flaw was found in util-linux. This vulnerability allows a heap buffer overread when processing 256-byte usernames, specifically within the `setpwnam()` function, affecting SUID (Set User ID) login-utils utilities writing to the password database.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libblkid1 > 0-0 (version in image is 2.37.4-150500.9.26.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix use-after-free when attempting to join an aborted transactionWhen we are trying to join the current transaction and if it's aborted,we read its 'aborted' field after unlocking fs_info->trans_lock andwithout holding any extra reference count on it. This means that aconcurrent task that is aborting the transaction may free the transactionbefore we read its 'aborted' field, leading to a use-after-free.Fix this by reading the 'aborted' field while holding fs_info->trans_locksince any freeing task must first acquire that lock and setfs_info->running_transaction to NULL before freeing the transaction.This was reported by syzbot and Dmitry with the following stack tracesfrom KASAN: ================================================================== BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128 CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events_unbound btrfs_async_reclaim_data_space Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803 btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 5315: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572 lookup_open fs/namei.c:3649 [inline] open_last_lookups fs/namei.c:3748 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3984 do_filp_open+0x27f/0x4e0 fs/namei.c:4014 do_sys_openat2+0x13e/0x1d0 fs/open.c:1402 do_sys_open fs/open.c:1417 [inline] __do_sys_creat fs/open.c:1495 [inline] __se_sys_creat fs/open.c:1489 [inline] __x64_sys_creat+0x123/0x170 fs/open.c:1489 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5336: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 cleanup_transaction fs/btrfs/transaction.c:2063 [inline] btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598 insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757 btrfs_balance+0x992/---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:orangefs: fix a oob in orangefs_debug_writeI got a syzbot report: slab-out-of-bounds Read inorangefs_debug_write... several people suggested fixes,I tested Al Viro's suggestion and made this patch.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ppp: Fix KMSAN uninit-value warning with bpfSyzbot caught an "KMSAN: uninit-value" warning [1], which is caused by theppp driver not initializing a 2-byte header when using socket filter.The following code can generate a PPP filter BPF program:'''struct bpf_program fp;pcap_t *handle;handle = pcap_open_dead(DLT_PPP_PPPD, 65535);pcap_compile(handle, &fp, "ip and outbound", 0, 0);bpf_dump(&fp, 1);'''Its output is:'''(000) ldh [2](001) jeq #0x21 jt 2 jf 5(002) ldb [0](003) jeq #0x1 jt 4 jf 5(004) ret #65535(005) ret #0'''Wen can find similar code at the following link:https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680The maintainer of this code repository is also the original maintainerof the ppp driver.As you can see the BPF program skips 2 bytes of data and then reads the'Protocol' field to determine if it's an IP packet. Then it read the firstbyte of the first 2 bytes to determine the direction.The issue is that only the first byte indicating direction is initializedin current ppp driver code while the second byte is not initialized.For normal BPF programs generated by libpcap, uninitialized data won't beused, so it's not a problem. However, for carefully crafted BPF programs,such as those generated by syzkaller [2], which start reading from offset0, the uninitialized data will be used and caught by KMSAN.[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791[2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix integer overflow while processing closetimeo mount optionUser-provided mount parameter closetimeo of type u32 is intended to havean upper limit, but before it is validated, the value is converted fromseconds to jiffies which can lead to an integer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: xhci: Apply the link chain quirk on NEC isoc endpointsTwo clearly different specimens of NEC uPD720200 (one with start/stopbug, one without) were seen to cause IOMMU faults after some MissedService Errors. Faulting address is immediately after a transfer ringsegment and patched dynamic debug messages revealed that the MSE wasreceived when waiting for a TD near the end of that segment:[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000][ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]It gets even funnier if the next page is a ring segment accessible tothe HC. Below, it reports MSE in segment at ff1e8000, plows through azero-filled page at ff1e9000 and starts reporting events for TRBs inpage at ff1ea000 every microframe, instead of jumping to seg ff1e6000.[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820At some point completion events change from Isoch Buffer Overrun toShort Packet and the HC finally finds cycle bit mismatch in ff1ec000.[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2It's possible that data from the isochronous device were written torandom buffers of pending TDs on other endpoints (either IN or OUT),other devices or even other HCs in the same IOMMU domain.Lastly, an error from a different USB device on another HC. Was itcaused by the above? I don't know, but it may have been. The diskwas working without any other issues and generated PCIe traffic tostarve the NEC of upstream BW and trigger those MSEs. The two HCsshared one x1 slot by means of a commercial "PCIe splitter" board.[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0Fortunately, it appears that this ridiculous bug is avoided by settingthe chain bit of Link TRBs on isochronous rings. Other ancient HCs areknown which also expect the bit to be set and they ignore Link TRBs ifit's not. Reportedly, 0.95 spec guaranteed that the bit is set.The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reportstens of MSEs per second and runs into the bug within seconds. ChainingLink TRBs allows the same workload to run for many minutes, many times.No ne---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix use-after-free in print_graph_function_flags during tracer switchingKairui reported a UAF issue in print_graph_function_flags() duringftrace stress testing [1]. This issue can be reproduced if puting a'mdelay(10)' after 'mutex_unlock(&trace_types_lock)' in s_start(),and executing the following script: $ echo function_graph > current_tracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > current_tracerThe root cause lies in the two calls to print_graph_function_flagswithin print_trace_line during each s_show(): * One through 'iter->trace->print_line()'; * Another through 'event->funcs->trace()', which is hidden in print_trace_fmt() before print_trace_line returns.Tracer switching only updates the former, while the latter continuesto use the print_line function of the old tracer, which in the scriptabove is print_graph_function_flags.Moreover, when switching from the 'function_graph' tracer to the'timerlat' tracer, s_start only calls graph_trace_close of the'function_graph' tracer to free 'iter->private', but does not setit to NULL. This provides an opportunity for 'event->funcs->trace()'to use an invalid 'iter->private'.To fix this issue, set 'iter->private' to NULL immediately afterfreeing it in graph_trace_close(), ensuring that an invalid pointeris not passed to other tracers. Additionally, clean up the unnecessary'iter->private = NULL' during each 'cat trace' when using wakeup andirqsoff tracers. [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Don't expose hw_counters outside of init net namespaceCommit 467f432a521a ("RDMA/core: Split port and device counter sysfsattributes") accidentally almost exposed hw counters to non-init netnamespaces. It didn't expose them fully, as an attempt to read any ofthose counters leads to a crash like this one:[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028[42021.814463] #PF: supervisor read access in kernel mode[42021.819549] #PF: error_code(0x0000) - not-present page[42021.824636] PGD 0 P4D 0[42021.827145] Oops: 0000 [#1] SMP PTI[42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX[42021.841697] Hardware name: XXX[42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core][42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff <48> 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48[42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287[42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000[42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0[42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000[42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530[42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000[42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000[42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0[42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[42021.949324] Call Trace:[42021.951756] [42021.953842] [] ? show_regs+0x64/0x70[42021.959030] [] ? __die+0x78/0xc0[42021.963874] [] ? page_fault_oops+0x2b5/0x3b0[42021.969749] [] ? exc_page_fault+0x1a2/0x3c0[42021.975549] [] ? asm_exc_page_fault+0x26/0x30[42021.981517] [] ? __pfx_show_hw_stats+0x10/0x10 [ib_core][42021.988482] [] ? hw_stat_device_show+0x1e/0x40 [ib_core][42021.995438] [] dev_attr_show+0x1e/0x50[42022.000803] [] sysfs_kf_seq_show+0x81/0xe0[42022.006508] [] seq_read_iter+0xf4/0x410[42022.011954] [] vfs_read+0x16e/0x2f0[42022.017058] [] ksys_read+0x6e/0xe0[42022.022073] [] do_syscall_64+0x6a/0xa0[42022.027441] [] entry_SYSCALL_64_after_hwframe+0x78/0xe2The problem can be reproduced using the following steps: ip netns add foo ip netns exec foo bash cat /sys/class/infiniband/mlx4_0/hw_counters/*The panic occurs because of casting the device pointer into anib_device pointer using container_of() in hw_stat_device_show() iswrong and leads to a memory corruption.However the real problem is that hw counters should never been exposedoutside of the non-init net namespace.Fix this by saving the index of the corresponding attribute group(it might be 1 or 2 depending on the presence of driver-specificattributes) and zeroing the pointer to hw_counters group for compatdevices during the initialization.With this fix applied hw_counters are not available in a non-initnet namespace: find /sys/class/infiniband/mlx4_0/ -name hw_counters /sys/class/infiniband/mlx4_0/ports/1/hw_counters /sys/class/infiniband/mlx4_0/ports/2/hw_counters /sys/class/infiniband/mlx4_0/hw_counters ip netns add foo ip netns exec foo bash find /sys/class/infiniband/mlx4_0/ -name hw_counters
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: Use kernel helpers for hex dumpsPreviously, when the driver was printing hex dumps, the buffer was castto an 8 byte long and printed using string formatters. If the buffersize was not a multiple of 8 then a read buffer overflow was possible.Therefore, create a new ibmvnic function that loops over a buffer andcalls hex_dump_to_buffer instead.This patch address KASAN reports like the one below: ibmvnic 30000003 env3: Login Buffer: ibmvnic 30000003 env3: 01000000af000000 <...> ibmvnic 30000003 env3: 2e6d62692e736261 ibmvnic 30000003 env3: 65050003006d6f63 ================================================================== BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic] Read of size 8 at addr c0000001331a9aa8 by task ip/17681 <...> Allocated by task 17681: <...> ibmvnic_login+0x2f0/0xffc [ibmvnic] ibmvnic_open+0x148/0x308 [ibmvnic] __dev_open+0x1ac/0x304 <...> The buggy address is located 168 bytes inside of allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf) <...> ================================================================= ibmvnic 30000003 env3: 000000000033766e
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef>> p *(struct pppoe_hdr *) (skb->head + skb->network_header)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 "4", data = 0xffff88803346f416 ":\377", truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,it is not safe to access data[2].[pabeni@redhat.com: fixed subj typo]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:padata: do not leak refcount in reorder_workA recent patch that addressed a UAF introduced a reference count leak:the parallel_data refcount is incremented unconditionally, regardlessof the return value of queue_work(). If the work item is already queued,the incremented refcount is never decremented.Fix this by checking the return value of queue_work() and decrementingthe refcount when necessary.Resolves:Unreferenced object 0xffff9d9f421e3d80 (size 192): comm "cryptomgr_probe", pid 157, jiffies 4294694003 hex dump (first 32 bytes): 80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............ d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#. backtrace (crc 838fb36): __kmalloc_cache_noprof+0x284/0x320 padata_alloc_pd+0x20/0x1e0 padata_alloc_shell+0x3b/0xa0 0xffffffffc040a54d cryptomgr_probe+0x43/0xc0 kthread+0xf6/0x1f0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hisi_acc_vfio_pci: fix XQE dma address errorThe dma addresses of EQE and AEQE are wrong after migration andresults in guest kernel-mode encryption services failure.Comparing the definition of hardware registers, we found thatthere was an error when the data read from the register wascombined into an address. Therefore, the address combinationsequence needs to be corrected.Even after fixing the above problem, we still have an issuewhere the Guest from an old kernel can get migrated tonew kernel and may result in wrong data.In order to ensure that the address is correct after migration,if an old magic number is detected, the dma address needs to beupdated.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: clear the dst when changing skb protocolA not-so-careful NAT46 BPF program can crash the kernelif it indiscriminately flips ingress packets from v4 to v6: BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6_rcv_core (net/ipv6/ip6_input.c:190:20) ipv6_rcv (net/ipv6/ip6_input.c:306:8) process_backlog (net/core/dev.c:6186:4) napi_poll (net/core/dev.c:6906:9) net_rx_action (net/core/dev.c:7028:13) do_softirq (kernel/softirq.c:462:3) netif_rx (net/core/dev.c:5326:3) dev_loopback_xmit (net/core/dev.c:4015:2) ip_mc_finish_output (net/ipv4/ip_output.c:363:8) NF_HOOK (./include/linux/netfilter.h:314:9) ip_mc_output (net/ipv4/ip_output.c:400:5) dst_output (./include/net/dst.h:459:9) ip_local_out (net/ipv4/ip_output.c:130:9) ip_send_skb (net/ipv4/ip_output.c:1496:8) udp_send_skb (net/ipv4/udp.c:1040:8) udp_sendmsg (net/ipv4/udp.c:1328:10)The output interface has a 4->6 program attached at ingress.We try to loop the multicast skb back to the sending socket.Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdrand changes skb->protocol to v6. We enter ip6_rcv_core whichtries to use skb_dst(). But the dst is still an IPv4 one leftafter IPv4 mcast output.Clear the dst in all BPF helpers which change the protocol.Try to preserve metadata dsts, those may carry non-routingmetadata.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: sch_sfq: reject invalid perturb periodGerrard Tai reported that SFQ perturb_period has no range check yet,and this can be used to trigger a race condition fixed in a separate patch.We want to make sure ctl->perturb_period * HZ will not overflowand is positive.tc qd add dev lo root sfq perturb -10 # negative value : errorError: sch_sfq: invalid perturb period.tc qd add dev lo root sfq perturb 1000000000 # too big : errorError: sch_sfq: invalid perturb period.tc qd add dev lo root sfq perturb 2000000 # acceptable valuetc -s -d qd sh dev loqdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell_rbu: Fix list usagePass the correct list head to list_for_each_entry*() when looping throughthe packet list.Without this patch, reading the packet data via sysfs will show the dataincorrectly (because it starts at the wrong packet), and clearing thepacket list will result in a NULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/iwcm: Fix use-after-free of work objects after cm_id destructionThe commit 59c68ac31e15 ("iw_cm: free cm_id resources on the lastderef") simplified cm_id resource management by freeing cm_id once allreferences to the cm_id were removed. The references are removed eitherupon completion of iw_cm event handlers or when the application destroysthe cm_id. This commit introduced the use-after-free condition wherecm_id_private object could still be in use by event handler works duringthe destruction of cm_id. The commit aee2424246f9 ("RDMA/iwcm: Fix ause-after-free related to destroying CM IDs") addressed this use-after-free by flushing all pending works at the cm_id destruction.However, still another use-after-free possibility remained. It happenswith the work objects allocated for each cm_id_priv withinalloc_work_entries() during cm_id creation, and subsequently freed indealloc_work_entries() once all references to the cm_id are removed.If the cm_id's last reference is decremented in the event handler work,the work object for the work itself gets removed, and causes the use-after-free BUG below: BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091 CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iw_cm_wq) Call Trace: dump_stack_lvl+0x6a/0x90 print_report+0x174/0x554 ? __virt_addr_valid+0x208/0x430 ? __pwq_activate_work+0x1ff/0x250 kasan_report+0xae/0x170 ? __pwq_activate_work+0x1ff/0x250 __pwq_activate_work+0x1ff/0x250 pwq_dec_nr_in_flight+0x8c5/0xfb0 process_one_work+0xc11/0x1460 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x16c/0x240 worker_thread+0x5ef/0xfd0 ? __pfx_worker_thread+0x10/0x10 kthread+0x3b0/0x770 ? __pfx_kthread+0x10/0x10 ? rcu_is_watching+0x11/0xb0 ? _raw_spin_unlock_irq+0x24/0x50 ? rcu_is_watching+0x11/0xb0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 147416: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 alloc_work_entries+0xa9/0x260 [iw_cm] iw_cm_connect+0x23/0x4a0 [iw_cm] rdma_connect_locked+0xbfd/0x1920 [rdma_cm] nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma] cma_cm_event_handler+0xae/0x320 [rdma_cm] cma_work_handler+0x106/0x1b0 [rdma_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 147091: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kfree+0x13a/0x4b0 dealloc_work_entries+0x125/0x1f0 [iw_cm] iwcm_deref_id+0x6f/0xa0 [iw_cm] cm_work_handler+0x136/0x1ba0 [iw_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Last potentially related work creation: kasan_save_stack+0x2c/0x50 kasan_record_aux_stack+0xa3/0xb0 __queue_work+0x2ff/0x1390 queue_work_on+0x67/0xc0 cm_event_handler+0x46a/0x820 [iw_cm] siw_cm_upcall+0x330/0x650 [siw] siw_cm_work_handler+0x6b9/0x2b20 [siw] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30This BUG is reproducible by repeating the blktests test case nvme/061for the rdma transport and the siw driver.To avoid the use-after-free of cm_id_private work objects, ensure thatthe last reference to the cm_id is decremented not in the event handlerworks, but in the cm_id destruction context. For that purpose, mo---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: inline: fix len overflow in ext4_prepare_inline_dataWhen running the following code on an ext4 filesystem with inline_datafeature enabled, it will lead to the bug below. fd = open("file1", O_RDWR | O_CREAT | O_TRUNC, 0666); ftruncate(fd, 30); pwrite(fd, "a", 1, (1UL << 40) + 5UL);That happens because write_begin will succeed as whenext4_generic_write_inline_data calls ext4_prepare_inline_data, pos + lenwill be truncated, leading to ext4_prepare_inline_data parameter to be 6instead of 0x10000000006.Then, later when write_end is called, we hit: BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);at ext4_write_inline_data.Fix it by using a loff_t type for the len parameter inext4_prepare_inline_data instead of an unsigned int.[ 44.545164] ------------[ cut here ]------------[ 44.545530] kernel BUG at fs/ext4/inline.c:240![ 44.545834] Oops: invalid opcode: 0000 [#1] SMP NOPTI[ 44.546172] CPU: 3 UID: 0 PID: 343 Comm: test Not tainted 6.15.0-rc2-00003-g9080916f4863 #45 PREEMPT(full) 112853fcebfdb93254270a7959841d2c6aa2c8bb[ 44.546523] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 44.546523] RIP: 0010:ext4_write_inline_data+0xfe/0x100[ 44.546523] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b <0f> 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49[ 44.546523] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216[ 44.546523] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006[ 44.546523] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738[ 44.546523] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000[ 44.546523] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000[ 44.546523] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738[ 44.546523] FS: 00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000[ 44.546523] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 44.546523] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0[ 44.546523] PKRU: 55555554[ 44.546523] Call Trace:[ 44.546523] [ 44.546523] ext4_write_inline_data_end+0x126/0x2d0[ 44.546523] generic_perform_write+0x17e/0x270[ 44.546523] ext4_buffered_write_iter+0xc8/0x170[ 44.546523] vfs_write+0x2be/0x3e0[ 44.546523] __x64_sys_pwrite64+0x6d/0xc0[ 44.546523] do_syscall_64+0x6a/0xf0[ 44.546523] ? __wake_up+0x89/0xb0[ 44.546523] ? xas_find+0x72/0x1c0[ 44.546523] ? next_uptodate_folio+0x317/0x330[ 44.546523] ? set_pte_range+0x1a6/0x270[ 44.546523] ? filemap_map_pages+0x6ee/0x840[ 44.546523] ? ext4_setattr+0x2fa/0x750[ 44.546523] ? do_pte_missing+0x128/0xf70[ 44.546523] ? security_inode_post_setattr+0x3e/0xd0[ 44.546523] ? ___pte_offset_map+0x19/0x100[ 44.546523] ? handle_mm_fault+0x721/0xa10[ 44.546523] ? do_user_addr_fault+0x197/0x730[ 44.546523] ? do_syscall_64+0x76/0xf0[ 44.546523] ? arch_exit_to_user_mode_prepare+0x1e/0x60[ 44.546523] ? irqentry_exit_to_user_mode+0x79/0x90[ 44.546523] entry_SYSCALL_64_after_hwframe+0x55/0x5d[ 44.546523] RIP: 0033:0x7f42999c6687[ 44.546523] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff[ 44.546523] RSP: 002b:00007ffeae4a7930 EFLAGS: 00000202 ORIG_RAX: 0000000000000012[ 44.546523] RAX: ffffffffffffffda RBX: 00007f4299934740 RCX: 00007f42999c6687[ 44.546523] RDX: 0000000000000001 RSI: 000055ea6149200f RDI: 0000000000000003[ 44.546523] RBP: 00007ffeae4a79a0 R08: 0000000000000000 R09: 0000000000000000[ 44.546523] R10: 0000010000000005 R11: 0000000000000202 R12: 0000---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: megaraid_sas: Fix invalid node indexOn a system with DRAM interleave enabled, out-of-bound access isdetected:megaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0------------[ cut here ]------------UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28index -1 is out of range for type 'cpumask *[1024]'dump_stack_lvl+0x5d/0x80ubsan_epilogue+0x5/0x2b__ubsan_handle_out_of_bounds.cold+0x46/0x4bmegasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas]megasas_probe_one.cold+0xa4d/0x189c [megaraid_sas]local_pci_probe+0x42/0x90pci_device_probe+0xdc/0x290really_probe+0xdb/0x340__driver_probe_device+0x78/0x110driver_probe_device+0x1f/0xa0__driver_attach+0xba/0x1c0bus_for_each_dev+0x8b/0xe0bus_add_driver+0x142/0x220driver_register+0x72/0xd0megasas_init+0xdf/0xff0 [megaraid_sas]do_one_initcall+0x57/0x310do_init_module+0x90/0x250init_module_from_file+0x85/0xc0idempotent_init_module+0x114/0x310__x64_sys_finit_module+0x65/0xc0do_syscall_64+0x82/0x170entry_SYSCALL_64_after_hwframe+0x76/0x7eFix it accordingly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3()In snd_usb_get_audioformat_uac3(), the length value returned fromsnd_usb_ctl_msg() is used directly for memory allocation withoutvalidation. This length is controlled by the USB device.The allocated buffer is cast to a uac3_cluster_header_descriptorand its fields are accessed without verifying that the bufferis large enough. If the device returns a smaller than expectedlength, this leads to an out-of-bounds read.Add a length check to ensure the buffer is large enough foruac3_cluster_header_descriptor.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: eir: Fix possible crashes on eir_create_adv_dataeir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWERwithout checking if that would fit.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:seg6: Fix validation of nexthop addressesThe kernel currently validates that the length of the provided nexthopaddress does not exceed the specified length. This can lead to thekernel reading uninitialized memory if user space provided a shorterlength than the specified one.Fix by validating that the provided length exactly matches the specifiedone.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/sgx: Prevent attempts to reclaim poisoned pagesTL;DR: SGX page reclaim touches the page to copy its contents tosecondary storage. SGX instructions do not gracefully handle machinechecks. Despite this, the existing SGX code will try to reclaim pagesthat it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages.The longer story:Pages used by an enclave only get epc_page->poison set inarch_memory_failure() but they currently stay on sgx_active_page_list untilsgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched.epc_page->poison is not checked in the reclaimer logic meaning that, if otherconditions are met, an attempt will be made to reclaim an EPC page that waspoisoned. This is bad because 1. we don't want that page to end up addedto another enclave and 2. it is likely to cause one core to shut downand the kernel to panic.Specifically, reclaiming uses microcode operations including "EWB" whichaccesses the EPC page contents to encrypt and write them out to non-SGXmemory. Those operations cannot handle MCEs in their accesses other thanby putting the executing core into a special shutdown state (affectingboth threads with HT.) The kernel will subsequently panic on theremaining cores seeing the core didn't enter MCE handler(s) in time.Call sgx_unmark_page_reclaimable() to remove the affected EPC page fromsgx_active_page_list on memory error to stop it being considered forreclaiming.Testing epc_page->poison in sgx_reclaim_pages() would also work but I assumeit's better to add code in the less likely paths.The affected EPC page is not added to &node->sgx_poison_page_list untillater in sgx_encl_release()->sgx_free_epc_page() when it is EREMOVEd.Membership on other lists doesn't change to avoid changing any of thelists' semantics except for sgx_active_page_list. There's a "TBD" commentin arch_memory_failure() about pre-emptive actions, the goal here is notto address everything that it may imply.This also doesn't completely close the time window when a memory errornotification will be fatal (for a not previously poisoned EPC page) --the MCE can happen after sgx_reclaim_pages() has selected its candidatesor even *inside* a microcode operation (actually easy to trigger due tothe amount of time spent in them.)The spinlock in sgx_unmark_page_reclaimable() is safe becausememory_failure() runs in process context and no spinlocks are held,explicitly noted in a mm/memory-failure.c comment.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/vmci: Clear the vmci transport packet properly when initializing itIn vmci_transport_packet_init memset the vmci_transport_packet beforepopulating the fields to avoid any uninitialised data being left in thestructure.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: tegra: check msg length in SMBUS block readFor SMBUS block read, do not continue to read if the message lengthpassed from the device is '0' or greater than the maximum allowed bytes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: account for Ethernet header in nf_flow_pppoe_proto()syzbot found a potential access to uninit-value in nf_flow_pppoe_proto()Blamed commit forgot the Ethernet header.BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27 nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline] nf_hook_slow+0xe1/0x3d0 net/netfilter/core.c:623 nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline] nf_ingress net/core/dev.c:5742 [inline] __netif_receive_skb_core+0x4aff/0x70c0 net/core/dev.c:5837 __netif_receive_skb_one_core net/core/dev.c:5975 [inline] __netif_receive_skb+0xcc/0xac0 net/core/dev.c:6090 netif_receive_skb_internal net/core/dev.c:6176 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6235 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x4ee0/0x6b40 drivers/net/tun.c:1938 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1984 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xb4b/0x1580 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: fix uaf in nbd_genl_connect() error pathThere is a use-after-free issue in nbd:block nbd6: Receive control failed (result -104)block nbd6: shutting down sockets==================================================================BUG: KASAN: slab-use-after-free in recv_work+0x694/0xa80 drivers/block/nbd.c:1022Write of size 4 at addr ffff8880295de478 by task kworker/u33:0/67CPU: 2 UID: 0 PID: 67 Comm: kworker/u33:0 Not tainted 6.15.0-rc5-syzkaller-00123-g2c89c1b655c0 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Workqueue: nbd6-recv recv_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_dec include/linux/atomic/atomic-instrumented.h:592 [inline] recv_work+0x694/0xa80 drivers/block/nbd.c:1022 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 nbd_genl_connect() does not properly stop the device on certainerror paths after nbd_start_device() has been called. This causesthe error path to put nbd->config while recv_work continue to usethe config after putting it, leading to use-after-free in recv_work.This patch moves nbd_start_device() after the backend file creation.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix oob access in cgroup local storageLonial reported that an out-of-bounds access in cgroup local storagecan be crafted via tail calls. Given two programs each utilizing acgroup local storage with a different value size, and one programdoing a tail call into the other. The verifier will validate each ofthe indivial programs just fine. However, in the runtime contextthe bpf_cg_run_ctx holds an bpf_prog_array_item which contains theBPF program as well as any cgroup local storage flavor the programuses. Helpers such as bpf_get_local_storage() pick this up from theruntime context: ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype]; if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf);For the second program which was called from the originally attachedone, this means bpf_get_local_storage() will pick up the formerprogram's map, not its own. With mismatching sizes, this can resultin an unintended out-of-bounds access.To fix this issue, we need to extend bpf_map_owner with an array ofstorage_cookie[] to match on i) the exact maps from the originalprogram if the second program was using bpf_get_local_storage(), orii) allow the tail call combination if the second program was notusing any of the cgroup local storage maps.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: aio_iiro_16: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: if ((1 << it->options[1]) & 0xdcfc) {However, `it->options[i]` is an unchecked `int` value from userspace, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test. Valid `it->options[1]` values that select the IRQwill be in the range [1,15]. The value 0 explicitly disables the use ofinterrupts.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: pcl812: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: if ((1 << it->options[1]) & board->irq_bits) {However, `it->options[i]` is an unchecked `int` value from userspace, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test. Valid `it->options[1]` values that select the IRQwill be in the range [1,15]. The value 0 explicitly disables the use ofinterrupts.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: common: st_sensors: Fix use of uninitialize device structsThroughout the various probe functions &indio_dev->dev is used before itis initialized. This caused a kernel panic in st_sensors_power_enable()when the call to devm_regulator_bulk_get_enable() fails and then callsdev_err_probe() with the uninitialized device.This seems to only cause a panic with dev_err_probe(), dev_err(),dev_warn() and dev_info() don't seem to cause a panic, but are fixedas well.The issue is reported and traced here: [1]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_nfacct: don't assume acct name is null-terminatedBUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851[..] string+0x231/0x2b0 lib/vsprintf.c:721 vsnprintf+0x739/0xf00 lib/vsprintf.c:2874 [..] nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41 xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523nfnl_acct_find_get() handles non-null input, but the errorprintk relied on its presence.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:parisc: Revise __get_user() to probe user read accessBecause of the way read access support is implemented, read accessinterruptions are only triggered at privilege levels 2 and 3. Thekernel executes at privilege level 0, so __get_user() never triggersa read access interruption (code 26). Thus, it is currently possiblefor user code to access a read protected address via a system call.Fix this by probing read access rights at privilege level 3 (PRIV_USER)and setting __gu_err to -EFAULT (-14) if access isn't allowed.Note the cmpiclr instruction does a 32-bit compare because COND macrodoesn't work inside asm.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/eesWhen we don't have a clock specified in the device tree, we have no way toensure the BAM is on. This is often the case for remotely-controlled orremotely-powered BAM instances. In this case, we need to read num-channelsfrom the DT to have all the necessary information to complete probing.However, at the moment invalid device trees without clock and withoutnum-channels still continue probing, because the error handling is missingreturn statements. The driver will then later try to read the number ofchannels from the registers. This is unsafe, because it relies on bootfirmware and lucky timing to succeed. Unfortunately, the lack of propererror handling here has been abused for several Qualcomm SoCs upstream,causing early boot crashes in several situations [1, 2].Avoid these early crashes by erroring out when any of the required DTproperties are missing. Note that this will break some of the existing DTsupstream (mainly BAM instances related to the crypto engine). However,clearly these DTs have never been tested properly, since the error in thekernel log was just ignored. It's safer to disable the crypto engine forthese broken DTBs.[1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/[2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:qed: Don't collect too many protection override GRC elementsIn the protection override dump path, the firmware can return far toomany GRC elements, resulting in attempting to write past the end of thepreviously-kmalloc'ed dump buffer.This will result in a kernel panic with reason: BUG: unable to handle kernel paging request at ADDRESSwhere "ADDRESS" is just past the end of the protection override dumpbuffer. The start address of the buffer is: p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_bufand the size of the buffer is buf_size in the same data structure.The panic can be arrived at from either the qede Ethernet driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc02662ed [qed] qed_dbg_protection_override_dump at ffffffffc0267792 [qed] qed_dbg_feature at ffffffffc026aa8f [qed] qed_dbg_all_data at ffffffffc026b211 [qed] qed_fw_fatal_reporter_dump at ffffffffc027298a [qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_report_fatal_error at ffffffffc0272baf [qed] qede_sp_task at ffffffffc045ed32 [qede] process_one_work at ffffffff81d19783or the qedf storage driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc068b2ed [qed] qed_dbg_protection_override_dump at ffffffffc068c792 [qed] qed_dbg_feature at ffffffffc068fa8f [qed] qed_dbg_all_data at ffffffffc0690211 [qed] qed_fw_fatal_reporter_dump at ffffffffc069798a [qed] devlink_health_do_dump at ffffffff8aa95e51 devlink_health_report at ffffffff8aa9ae19 qed_report_fatal_error at ffffffffc0697baf [qed] qed_hw_err_notify at ffffffffc06d32d7 [qed] qed_spq_post at ffffffffc06b1011 [qed] qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed] qedf_cleanup_fcport at ffffffffc05e7597 [qedf] qedf_rport_event_handler at ffffffffc05e7bf7 [qedf] fc_rport_work at ffffffffc02da715 [libfc] process_one_work at ffffffff8a319663Resolve this by clamping the firmware's return value to the maximumnumber of legal elements the firmware should return.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rskin the TCP_ESTABLISHED state. [0]syzbot reused the server-side TCP Fast Open socket as a new client beforethe TFO socket completes 3WHS: 1. accept() 2. connect(AF_UNSPEC) 3. connect() to another destinationAs of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changesit to TCP_CLOSE and makes connect() possible, which restarts timers.Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, theretransmit timer triggered the warning and the intended packet was notretransmitted.Let's call reqsk_fastopen_remove() in tcp_disconnect().[0]:WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))Modules linked in:CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3eRSP: 0018:ffffc900002f8d40 EFLAGS: 00010293RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0Call Trace: tcp_write_timer (net/ipv4/tcp_timer.c:738) call_timer_fn (kernel/time/timer.c:1747) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035) __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1)) tmigr_handle_remote (kernel/time/timer_migration.c:1096) handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix input validation logic for action_metaFix condition to check 'greater or equal' to prevent OOB dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: target_core_configfs: Add length check to avoid buffer overflowA buffer overflow arises from the usage of snprintf to write into thebuffer "buf" in target_lu_gp_members_show function located in/drivers/target/target_core_configfs.c. This buffer is allocated withsize LU_GROUP_NAME_BUF (256 bytes).snprintf(...) formats multiple strings into buf with the HBA name(hba->hba_group.cg_item), a slash character, a devicename (dev->dev_group.cg_item) and a newline character, the total formatted stringlength may exceed the buffer size of 256 bytes.Since snprintf() returns the total number of bytes that would have beenwritten (the length of %s/%sn ), this value may exceed the buffer length(256 bytes) passed to memcpy(), this will ultimately cause functionmemcpy reporting a buffer overflow error.An additional check of the return value of snprintf() can avoid thisbuffer overflow.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: fix uninit-value in squashfs_get_parentSyzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.This is caused by open_by_handle_at() being called with a file handlecontaining an invalid parent inode number. In particular the inode numberis that of a symbolic link, rather than a directory.Squashfs_get_parent() gets called with that symbolic link inode, andaccesses the parent member field. unsigned int parent_ino = squashfs_i(inode)->parent;Because non-directory inodes in Squashfs do not have a parent value, thisis uninitialised, and this causes an uninitialised value access.The fix is to initialise parent with the invalid inode 0, which will causean EINVAL error to be returned.Regular inodes used to share the parent field with the block_list_startfield. This is removed in this commit to enable the parent field tocontain the invalid inode number 0.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix NULL pointer deference in try_to_register_cardIn try_to_register_card(), the return value of usb_ifnum_to_if() ispassed directly to usb_interface_claimed() without a NULL check, whichwill lead to a NULL pointer dereference when creating an invalidUSB audio device. Fix this by adding a check to ensure the interfacepointer is valid before passing it to usb_interface_claimed().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU in ip6_xmit()Use RCU in ip6_xmit() in order to use dst_dev_rcu() to preventpossible UAF.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: guard against EA inode refcount underflow in xattr updatesyzkaller found a path where ext4_xattr_inode_update_ref() reads an EAinode refcount that is already <= 0 and then applies ref_change (often-1). That lets the refcount underflow and we proceed with a bogus value,triggering errors like: EXT4-fs error: EA inode ref underflow: ref_count=-1 ref_change=-1 EXT4-fs warning: ea_inode dec ref err=-117Make the invariant explicit: if the current refcount is non-positive,treat this as on-disk corruption, emit ext4_error_inode(), and fail theoperation with -EFSCORRUPTED instead of updating the refcount. Delete theWARN_ONCE() as negative refcounts are now impossible; keep error reportingin ext4_error_inode().This prevents the underflow and the follow-on orphan/cleanup churn.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: fix crash in set_mesh_sync and set_mesh_completeThere is a BUG: KASAN: stack-out-of-bounds in set_mesh_sync due tomemcpy from badly declared on-stack flexible array.Another crash is in set_mesh_complete() due to double list_del viamgmt_pending_valid + mgmt_pending_remove.Use DEFINE_FLEX to declare the flexible array right, and don't memcpyoutside bounds.As mgmt_pending_valid removes the cmd from list, use mgmt_pending_free,and also report status on error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadgetIn the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadgetstructure (pdev->gadget) was freed before its endpoints.The endpoints are linked via the ep_list in the gadget structure.Freeing the gadget first leaves dangling pointers in the endpoint list.When the endpoints are subsequently freed, this results in a use-after-free.Fix:By separating the usb_del_gadget_udc() operation into distinct "del" and"put" steps, cdnsp_gadget_free_endpoints() can be executed prior to thefinal release of the gadget structure with usb_put_gadget().A patch similar to bb9c74a5bd14("usb: dwc3: gadget: Free gadget structure only after freeing endpoints").
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: stratix10-svc: fix bug in saving controller dataFix the incorrect usage of platform_set_drvdata and dev_set_drvdata. Theyboth are of the same data and overrides each other. This resulted in thermmod of the svc driver to fail and throw a kernel panic for kthread_stopand fifo free.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:backlight: led-bl: Add devlink to supplier LEDsLED Backlight is a consumer of one or multiple LED class devices, butdevlink is currently unable to create correct supplier-producer links whenthe supplier is a class device. It creates instead a link where thesupplier is the parent of the expected device.One consequence is that removal order is not correctly enforced.Issues happen for example with the following sections in a device treeoverlay: // An LED driver chip pca9632@62 { compatible = "nxp,pca9632"; reg = <0x62>; // ... addon_led_pwm: led-pwm@3 { reg = <3>; label = "addon:led:pwm"; }; }; backlight-addon { compatible = "led-backlight"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; };In this example, the devlink should be created between the backlight-addon(consumer) and the pca9632@62 (supplier). Instead it is created between thebacklight-addon (consumer) and the parent of the pca9632@62, which istypically the I2C bus adapter.On removal of the above overlay, the LED driver can be removed before thebacklight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98Another way to reproduce the bug without any device tree overlays isunbinding the LED class device (pca9632@62) before unbinding the consumer(backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbindFix by adding a devlink between the consuming led-backlight device and thesupplying LED device, as other drivers and subsystems do as well.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sock: fix hardened usercopy panic in sock_recv_errqueueskbuff_fclone_cache was created without defining a usercopy region,[1] unlike skbuff_head_cache which properly whitelists the cb[] field.[2] This causes a usercopy BUG() when CONFIG_HARDENED_USERCOPY isenabled and the kernel attempts to copy sk_buff.cb data to userspacevia sock_recv_errqueue() -> put_cmsg().The crash occurs when: 1. TCP allocates an skb using alloc_skb_fclone() (from skbuff_fclone_cache) [1]2. The skb is cloned via skb_clone() using the pre-allocated fclone[3] 3. The cloned skb is queued to sk_error_queue for timestampreporting 4. Userspace reads the error queue via recvmsg(MSG_ERRQUEUE)5. sock_recv_errqueue() calls put_cmsg() to copy serr->ee from skb->cb[4] 6. __check_heap_object() fails because skbuff_fclone_cache has no usercopy whitelist [5]When cloned skbs allocated from skbuff_fclone_cache are used in thesocket error queue, accessing the sock_exterr_skb structure in skb->cbvia put_cmsg() triggers a usercopy hardening violation:[ 5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object 'skbuff_fclone_cache' (offset 296, size 16)![ 5.382796] kernel BUG at mm/usercopy.c:102![ 5.383923] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI[ 5.384903] CPU: 1 UID: 0 PID: 138 Comm: poc_put_cmsg Not tainted 6.12.57 #7[ 5.384903] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014[ 5.384903] RIP: 0010:usercopy_abort+0x6c/0x80[ 5.384903] Code: 1a 86 51 48 c7 c2 40 15 1a 86 41 52 48 c7 c7 c0 15 1a 86 48 0f 45 d6 48 c7 c6 80 15 1a 86 48 89 c1 49 0f 45 f3 e8 84 27 88 ff <0f> 0b 490[ 5.384903] RSP: 0018:ffffc900006f77a8 EFLAGS: 00010246[ 5.384903] RAX: 000000000000006f RBX: ffff88800f0ad2a8 RCX: 1ffffffff0f72e74[ 5.384903] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff87b973a0[ 5.384903] RBP: 0000000000000010 R08: 0000000000000000 R09: fffffbfff0f72e74[ 5.384903] R10: 0000000000000003 R11: 79706f6372657375 R12: 0000000000000001[ 5.384903] R13: ffff88800f0ad2b8 R14: ffffea00003c2b40 R15: ffffea00003c2b00[ 5.384903] FS: 0000000011bc4380(0000) GS:ffff8880bf100000(0000) knlGS:0000000000000000[ 5.384903] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 5.384903] CR2: 000056aa3b8e5fe4 CR3: 000000000ea26004 CR4: 0000000000770ef0[ 5.384903] PKRU: 55555554[ 5.384903] Call Trace:[ 5.384903] [ 5.384903] __check_heap_object+0x9a/0xd0[ 5.384903] __check_object_size+0x46c/0x690[ 5.384903] put_cmsg+0x129/0x5e0[ 5.384903] sock_recv_errqueue+0x22f/0x380[ 5.384903] tls_sw_recvmsg+0x7ed/0x1960[ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5[ 5.384903] ? schedule+0x6d/0x270[ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5[ 5.384903] ? mutex_unlock+0x81/0xd0[ 5.384903] ? __pfx_mutex_unlock+0x10/0x10[ 5.384903] ? __pfx_tls_sw_recvmsg+0x10/0x10[ 5.384903] ? _raw_spin_lock_irqsave+0x8f/0xf0[ 5.384903] ? _raw_read_unlock_irqrestore+0x20/0x40[ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5The crash offset 296 corresponds to skb2->cb within skbuff_fclones: - sizeof(struct sk_buff) = 232 - offsetof(struct sk_buff, cb) = 40 - offset of skb2.cb in fclones = 232 + 40 = 272 - crash offset 296 = 272 + 24 (inside sock_exterr_skb.ee)This patch uses a local stack variable as a bounce buffer to avoid the hardened usercopy check failure.[1] https://elixir.bootlin.com/linux/v6.12.62/source/net/ipv4/tcp.c#L885[2] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5104[3] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5566[4] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5491[5] https://elixir.bootlin.com/linux/v6.12.62/source/mm/slub.c#L5719
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: avoid kernel-infoleak from struct iw_pointstruct iw_point has a 32bit hole on 64bit arches.struct iw_point { void __user *pointer; /* Pointer to the data (in user space) */ __u16 length; /* number of fields or size in bytes */ __u16 flags; /* Optional params */};Make sure to zero the structure to avoid disclosing 32bits of kernel datato user space.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovecnvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDUlength or offset exceeds sg_cnt and then use bogus sg->length/offsetvalues, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remainingentries, and sg->length/offset before building the bvec.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: serialize lock/unlock against other NAND operationsnand_lock() and nand_unlock() call into chip->ops.lock_area/unlock_areawithout holding the NAND device lock. On controllers that implementSET_FEATURES via multiple low-level PIO commands, these can race withconcurrent UBI/UBIFS background erase/write operations that hold thedevice lock, resulting in cmd_pending conflicts on the NAND controller.Add nand_get_device()/nand_release_device() around the lock/unlockoperations to serialize them against all other NAND controller access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: cdc_ncm: add ndpoffset to NDP32 nframes bounds checkThe same bounds-check bug fixed for NDP16 in the previous patch alsoexists in cdc_ncm_rx_verify_ndp32(). The DPE array size is validatedagainst the total skb length without accounting for ndpoffset, allowingout-of-bounds reads when the NDP32 is placed near the end of the NTB.Add ndpoffset to the nframes bounds check and use struct_size_t() toexpress the NDP-plus-DPE-array size more clearly.Compile-tested only.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: vidtv: fix nfeeds state corruption on start_streaming failuresyzbot reported a memory leak in vidtv_psi_service_desc_init [1].When vidtv_start_streaming() fails inside vidtv_start_feed(), thenfeeds counter is left incremented even though no feed was actuallystarted. This corrupts the driver state: subsequent start_feed callssee nfeeds > 1 and skip starting the mux, while stop_feed callseventually try to stop a non-existent stream.This state corruption can also lead to memory leaks, since the muxand channel resources may be partially allocated during a failedstart_streaming but never cleaned up, as the stop path findsdvb->streaming == false and returns early.Fix by decrementing nfeeds back when start_streaming fails, keepingthe counter in sync with the actual number of active feeds.[1]BUG: memory leakunreferenced object 0xffff888145b50820 (size 32): comm "syz.0.17", pid 6068, jiffies 4294944486 backtrace (crc 90a0c7d4): vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288 vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83 vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524 vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: jq is a command-line JSON processor. In commits before 2f09060afab23fe9390cce7cb860b10416e1bf5f, the jv_parse_sized() API in libjq accepts a counted buffer with an explicit length parameter, but its error-handling path formats the input buffer using %s in jv_string_fmt(), which reads until a NUL terminator is found rather than respecting the caller-supplied length. This means that when malformed JSON is passed in a non-NUL-terminated buffer, the error construction logic performs an out-of-bounds read past the end of the buffer. The vulnerability is reachable by any libjq consumer calling jv_parse_sized() with untrusted input, and depending on memory layout, can result in memory disclosure or process termination. The issue has been patched in commit 2f09060afab23fe9390cce7cb860b10416e1bf5f.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.1).
-
Description: Unknown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.56.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dcache: Limit the minimal number of bucket to twoThere is an OOB read problem on dentry_hashtable when user sets'dhash_entries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:__d_lookup+0x56/0x120 Call Trace: d_lookup.cold+0x16/0x5d lookup_dcache+0x27/0xf0 lookup_one_qstr_excl+0x2a/0x180 start_dirop+0x55/0xa0 simple_start_creating+0x8d/0xa0 debugfs_start_creating+0x8c/0x180 debugfs_create_dir+0x1d/0x1c0 pinctrl_init+0x6d/0x140 do_one_initcall+0x6d/0x3d0 kernel_init_freeable+0x39f/0x460 kernel_init+0x2a/0x260There will be only one bucket in dentry_hashtable when dhash_entries isset as one, and d_hash_shift is calculated as 32 by dcache_init(). Then,following process will access more than one buckets(which memory regionis not allocated) in dentry_hashtable: d_lookup b = d_hash(hash) dentry_hashtable + ((u32)hashlen >> d_hash_shift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlist_bl_for_each_entry_rcu(b) hlist_bl_first_rcu(head) h->first // read OOB!Fix it by limiting the minimal number of dentry_hashtable bucket to two,so that 'd_hash_shift' won't exceeds the bit width of type u32.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix reference state management for synchronous callbacksCurrently, verifier verifies callback functions (sync and async) as ifthey will be executed once, (i.e. it explores execution state as if thefunction was being called once). The next insn to explore is set tostart of subprog and the exit from nested frame is handled usingcurframe > 0 and prepare_func_exit. In case of async callback it uses acustomized variant of push_stack simulating a kind of branch to set upcustom state and execution context for the async callback.While this approach is simple and works when callback really will beexecuted only once, it is unsafe for all of our current helpers whichare for_each style, i.e. they execute the callback multiple times.A callback releasing acquired references of the caller may do somultiple times, but currently verifier sees it as one call inside theframe, which then returns to caller. Hence, it thinks it released somereference that the cb e.g. got access through callback_ctx (registerfilled inside cb from spilled typed register on stack).Similarly, it may see that an acquire call is unpaired inside thecallback, so the caller will copy the reference state of callback andthen will have to release the register with new ref_obj_ids. But again,the callback may execute multiple times, but the verifier will onlyaccount for acquired references for a single symbolic execution of thecallback, which will cause leaks.Note that for async callback case, things are different. While currentlywe have bpf_timer_set_callback which only executes it once, even formultiple executions it would be safe, as reference state is NULL andcheck_reference_leak would force program to release state beforeBPF_EXIT. The state is also unaffected by analysis for the caller frame.Hence async callback is safe.Since we want the reference state to be accessible, e.g. for pointersloaded from stack through callback_ctx's PTR_TO_STACK, we still have tocopy caller's reference_state to callback's bpf_func_state, but weenforce that whatever references it adds to that reference_state hasbeen released before it hits BPF_EXIT. This requires introducing a newcallback_ref member in the reference state to distinguish between callervs callee references. Hence, check_reference_leak now errors out if itsees we are in callback_fn and we have not released callback_ref refs.Since there can be multiple nested callbacks, like frame 0 -> cb1 -> cb2etc. we need to also distinguish between whether this particular refbelongs to this callback frame or parent, and only error for our own, sowe store state->frameno (which is always non-zero for callbacks).In short, callbacks can read parent reference_state, but cannot mutateit, to be able to use pointers acquired by the caller. They must onlyundo their changes (by releasing their own acquired_refs beforeBPF_EXIT) on top of caller reference_state before returning (at whichpoint the caller and callback state will match anyway, so no need tocopy it back to caller).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Fix multiple LUN_RESET handlingThis fixes a bug where an initiator thinks a LUN_RESET has cleaned uprunning commands when it hasn't. The bug was added in commit 51ec502a3266("target: Delete tmr from list before processing").The problem occurs when: 1. We have N I/O cmds running in the target layer spread over 2 sessions. 2. The initiator sends a LUN_RESET for each session. 3. session1's LUN_RESET loops over all the running commands from both sessions and moves them to its local drain_task_list. 4. session2's LUN_RESET does not see the LUN_RESET from session1 because the commit above has it remove itself. session2 also does not see any commands since the other reset moved them off the state lists. 5. sessions2's LUN_RESET will then complete with a successful response. 6. sessions2's inititor believes the running commands on its session are now cleaned up due to the successful response and cleans up the running commands from its side. It then restarts them. 7. The commands do eventually complete on the backend and the target starts to return aborted task statuses for them. The initiator will either throw a invalid ITT error or might accidentally lookup a new task if the ITT has been reallocated already.Fix the bug by reverting the patch, and serialize the execution ofLUN_RESETs and Preempt and Aborts.Also prevent us from waiting on LUN_RESETs in core_tmr_drain_tmr_list,because it turns out the original patch fixed a bug that was notmentioned. For LUN_RESET1 core_tmr_drain_tmr_list can see a secondLUN_RESET and wait on it. Then the second reset will runcore_tmr_drain_tmr_list and see the first reset and wait on it resulting ina deadlock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/slub: Avoid list corruption when removing a slab from the full listBoot with slub_debug=UFPZ.If allocated object failed in alloc_consistency_checks, all objects ofthe slab will be marked as used, and then the slab will be removed fromthe partial list.When an object belonging to the slab got freed later, the remove_full()function is called. Because the slab is neither on the partial list noron the full list, it eventually lead to a list corruption (actually alist poison being detected).So we need to mark and isolate the slab page with metadata corruption,do not put it back in circulation.Because the debug caches avoid all the fastpaths, reusing the frozen bitto mark slab page with metadata corruption seems to be fine.[ 4277.385669] list_del corruption, ffffea00044b3e50->next is LIST_POISON1 (dead000000000100)[ 4277.387023] ------------[ cut here ]------------[ 4277.387880] kernel BUG at lib/list_debug.c:56![ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI[ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G OE 6.6.1-1 #1[ 4277.392113] Workqueue: xfs-inodegc/vda1 xfs_inodegc_worker [xfs][ 4277.393551] RIP: 0010:__list_del_entry_valid_or_report+0x7b/0xc0[ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91[ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082[ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000[ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff[ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0[ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910[ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0[ 4277.404049] FS: 0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000[ 4277.405357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0[ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 4277.410000] PKRU: 55555554[ 4277.410645] Call Trace:[ 4277.411234] [ 4277.411777] ? die+0x32/0x80[ 4277.412439] ? do_trap+0xd6/0x100[ 4277.413150] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.414158] ? do_error_trap+0x6a/0x90[ 4277.414948] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.415915] ? exc_invalid_op+0x4c/0x60[ 4277.416710] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.417675] ? asm_exc_invalid_op+0x16/0x20[ 4277.418482] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.419466] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.420410] free_to_partial_list+0x515/0x5e0[ 4277.421242] ? xfs_iext_remove+0x41a/0xa10 [xfs][ 4277.422298] xfs_iext_remove+0x41a/0xa10 [xfs][ 4277.423316] ? xfs_inodegc_worker+0xb4/0x1a0 [xfs][ 4277.424383] xfs_bmap_del_extent_delay+0x4fe/0x7d0 [xfs][ 4277.425490] __xfs_bunmapi+0x50d/0x840 [xfs][ 4277.426445] xfs_itruncate_extents_flags+0x13a/0x490 [xfs][ 4277.427553] xfs_inactive_truncate+0xa3/0x120 [xfs][ 4277.428567] xfs_inactive+0x22d/0x290 [xfs][ 4277.429500] xfs_inodegc_worker+0xb4/0x1a0 [xfs][ 4277.430479] process_one_work+0x171/0x340[ 4277.431227] worker_thread+0x277/0x390[ 4277.431962] ? __pfx_worker_thread+0x10/0x10[ 4277.432752] kthread+0xf0/0x120[ 4277.433382] ? __pfx_kthread+0x10/0x10[ 4277.434134] ret_from_fork+0x2d/0x50[ 4277.434837] ? __pfx_kthread+0x10/0x10[ 4277.435566] ret_from_fork_asm+0x1b/0x30[ 4277.436280]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: fix potential buffer overflow in do_register_framebuffer()The current implementation may lead to buffer overflow when:1. Unregistration creates NULL gaps in registered_fb[]2. All array slots become occupied despite num_registered_fb < FB_MAX3. The registration loop exceeds array boundsAdd boundary check to prevent registered_fb[FB_MAX] access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rtosyzbot reported a possible shift-out-of-bounds [1]Blamed commit added rto_alpha_max and rto_beta_max set to 1000.It is unclear if some sctp users are setting very large rto_alphaand/or rto_beta.In order to prevent user regression, perform the test at run time.Also add READ_ONCE() annotations as sysctl values can change under us.[1]UBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41shift exponent 64 is too large for 32-bit type 'unsigned int'CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:233 [inline] __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494 sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509 sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502 sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338 sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: account for current allocated stack depth in widen_imprecise_scalars()The usage pattern for widen_imprecise_scalars() looks as follows: prev_st = find_prev_entry(env, ...); queued_st = push_stack(...); widen_imprecise_scalars(env, prev_st, queued_st);Where prev_st is an ancestor of the queued_st in the explored statestree. This ancestor is not guaranteed to have same allocated stackdepth as queued_st. E.g. in the following case: def main(): for i in 1..2: foo(i) // same callsite, differnt param def foo(i): if i == 1: use 128 bytes of stack iterator based loopHere, for a second 'foo' call prev_st->allocated_stack is 128,while queued_st->allocated_stack is much smaller.widen_imprecise_scalars() needs to take this into account and avoidaccessing bpf_verifier_state->frame[*]->stack out of bounds.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm8001: Fix use-after-free in pm8001_queue_command()Commit e29c47fe8946 ("scsi: pm8001: Simplify pm8001_task_exec()") refactorspm8001_queue_command(), however it introduces a potential cause of a doublefree scenario when it changes the function to return -ENODEV in case of phydown/device gone state.In this path, pm8001_queue_command() updates task status and callstask_done to indicate to upper layer that the task has been handled.However, this also frees the underlying SAS task. A -ENODEV is thenreturned to the caller. When libsas sas_ata_qc_issue() receives this errorvalue, it assumes the task wasn't handled/queued by LLDD and proceeds toclean up and free the task again, resulting in a double free.Since pm8001_queue_command() handles the SAS task in this case, it shouldreturn 0 to the caller indicating that the task has been handled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- vim > 0-0 (version in image is 9.2.0280-150500.20.46.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: avoid buffer leaks on xdp_do_redirect() failureBefore enetc_clean_rx_ring_xdp() calls xdp_do_redirect(), each softwareBD in the RX ring between index orig_i and i can have one of 2 refcountvalues on its page.We are the owner of the current buffer that is being processed, so therefcount will be at least 1.If the current owner of the buffer at the diametrically opposed indexin the RX ring (i.o.w, the other half of this page) has not yet calledkfree(), this page's refcount could even be 2.enetc_page_reusable() in enetc_flip_rx_buff() tests for the pagerefcount against 1, and [ if it's 2 ] does not attempt to reuse it.But if enetc_flip_rx_buff() is put after the xdp_do_redirect() call,the page refcount can have one of 3 values. It can also be 0, if thereis no owner of the other page half, and xdp_do_redirect() for thisbuffer ran so far that it triggered a flush of the devmap/cpumap bulkqueue, and the consumers of those bulk queues also freed the buffer,all by the time xdp_do_redirect() returns the execution back to enetc.This is the reason why enetc_flip_rx_buff() is called beforexdp_do_redirect(), but there is a big flaw with that reasoning:enetc_flip_rx_buff() will set rx_swbd->page = NULL on both sides of theenetc_page_reusable() branch, and if xdp_do_redirect() returns an error,we call enetc_xdp_free(), which does not deal gracefully with that.In fact, what happens is quite special. The page refcounts start as 1.enetc_flip_rx_buff() figures they're reusable, transfers theserx_swbd->page pointers to a different rx_swbd in enetc_reuse_page(), andbumps the refcount to 2. When xdp_do_redirect() later returns an error,we call the no-op enetc_xdp_free(), but we still haven't lost thereference to that page. A copy of it is still at rx_ring->next_to_alloc,but that has refcount 2 (and there are no concurrent owners of it inflight, to drop the refcount). What really kills the system is whenwe'll flip the rx_swbd->page the second time around. With an updatedrefcount of 2, the page will not be reusable and we'll really leak it.Then enetc_new_page() will have to allocate more pages, which will theneventually leak again on further errors from xdp_do_redirect().The problem, summarized, is that we zeroize rx_swbd->page before we'recompletely done with it, and this makes it impossible for the error pathto do something with it.Since the packet is potentially multi-buffer and therefore therx_swbd->page is potentially an array, manual passing of the oldpointers between enetc_flip_rx_buff() and enetc_xdp_free() is a bitdifficult.For the sake of going with a simple solution, we accept the possibilityof racing with xdp_do_redirect(), and we move the flip procedure toexecute only on the redirect success path. By racing, I mean that thepage may be deemed as not reusable by enetc (having a refcount of 0),but there will be no leak in that case, either.Once we accept that, we have something better to do with buffers onXDP_REDIRECT failure. Since we haven't performed half-page flipping yet,we won't, either (and this way, we can avoid enetc_xdp_free()completely, which gives the entire page to the slab allocator).Instead, we'll call enetc_xdp_drop(), which will recycle this half ofthe buffer back to the RX ring.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Update ipcomp_scratches with NULL when freedCurrently if ipcomp_alloc_scratches() fails to allocate memoryipcomp_scratches holds obsolete address. So when we try to free thepercpu scratches using ipcomp_free_scratches() it tries to vfree nonexistent vm area. Described below:static void * __percpu *ipcomp_alloc_scratches(void){ ... scratches = alloc_percpu(void *); if (!scratches) return NULL;ipcomp_scratches does not know about this allocation failure.Therefore holding the old obsolete address. ...}So when we free,static void ipcomp_free_scratches(void){ ... scratches = ipcomp_scratches;Assigning obsolete address from ipcomp_scratches if (!scratches) return; for_each_possible_cpu(i) vfree(*per_cpu_ptr(scratches, i));Trying to free non existent page, causing warning: trying to vfreeexistent vm area. ...}Fix this breakage by updating ipcomp_scrtches with NULL when scratchesis freed
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix soft lockups in fib6_select_path under high next hop churnSoft lockups have been observed on a cluster of Linux-based edge routerslocated in a highly dynamic environment. Using the `bird` service, theserouters continuously update BGP-advertised routes due to frequentlychanging nexthop destinations, while also managing significant IPv6traffic. The lockups occur during the traversal of the multipathcircular linked-list in the `fib6_select_path` function, particularlywhile iterating through the siblings in the list. The issue typicallyarises when the nodes of the linked list are unexpectedly deletedconcurrently on a different core-indicated by their 'next' and'previous' elements pointing back to the node itself and their referencecount dropping to zero. This results in an infinite loop, leading to asoft lockup that triggers a system panic via the watchdog timer.Apply RCU primitives in the problematic code sections to resolve theissue. Where necessary, update the references to fib6_siblings toannotate or use the RCU APIs.Include a test script that reproduces the issue. The scriptperiodically updates the routing table while generating a heavy loadof outgoing IPv6 traffic through multiple iperf3 clients. Itconsistently induces infinite soft lockups within a couple of minutes.Kernel log: 0 [ffffbd13003e8d30] machine_kexec at ffffffff8ceaf3eb 1 [ffffbd13003e8d90] __crash_kexec at ffffffff8d0120e3 2 [ffffbd13003e8e58] panic at ffffffff8cef65d4 3 [ffffbd13003e8ed8] watchdog_timer_fn at ffffffff8d05cb03 4 [ffffbd13003e8f08] __hrtimer_run_queues at ffffffff8cfec62f 5 [ffffbd13003e8f70] hrtimer_interrupt at ffffffff8cfed756 6 [ffffbd13003e8fd0] __sysvec_apic_timer_interrupt at ffffffff8cea01af 7 [ffffbd13003e8ff0] sysvec_apic_timer_interrupt at ffffffff8df1b83d-- -- 8 [ffffbd13003d3708] asm_sysvec_apic_timer_interrupt at ffffffff8e000ecb [exception RIP: fib6_select_path+299] RIP: ffffffff8ddafe7b RSP: ffffbd13003d37b8 RFLAGS: 00000287 RAX: ffff975850b43600 RBX: ffff975850b40200 RCX: 0000000000000000 RDX: 000000003fffffff RSI: 0000000051d383e4 RDI: ffff975850b43618 RBP: ffffbd13003d3800 R8: 0000000000000000 R9: ffff975850b40200 R10: 0000000000000000 R11: 0000000000000000 R12: ffffbd13003d3830 R13: ffff975850b436a8 R14: ffff975850b43600 R15: 0000000000000007 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 9 [ffffbd13003d3808] ip6_pol_route at ffffffff8ddb030c10 [ffffbd13003d3888] ip6_pol_route_input at ffffffff8ddb068c11 [ffffbd13003d3898] fib6_rule_lookup at ffffffff8ddf02b512 [ffffbd13003d3928] ip6_route_input at ffffffff8ddb0f4713 [ffffbd13003d3a18] ip6_rcv_finish_core.constprop.0 at ffffffff8dd950d014 [ffffbd13003d3a30] ip6_list_rcv_finish.constprop.0 at ffffffff8dd9627415 [ffffbd13003d3a98] ip6_sublist_rcv at ffffffff8dd9647416 [ffffbd13003d3af8] ipv6_list_rcv at ffffffff8dd9661517 [ffffbd13003d3b60] __netif_receive_skb_list_core at ffffffff8dc16fec18 [ffffbd13003d3be0] netif_receive_skb_list_internal at ffffffff8dc176b319 [ffffbd13003d3c50] napi_gro_receive at ffffffff8dc565b920 [ffffbd13003d3c80] ice_receive_skb at ffffffffc087e4f5 [ice]21 [ffffbd13003d3c90] ice_clean_rx_irq at ffffffffc0881b80 [ice]22 [ffffbd13003d3d20] ice_napi_poll at ffffffffc088232f [ice]23 [ffffbd13003d3d80] __napi_poll at ffffffff8dc1800024 [ffffbd13003d3db8] net_rx_action at ffffffff8dc1858125 [ffffbd13003d3e40] __do_softirq at ffffffff8df352e926 [ffffbd13003d3eb0] run_ksoftirqd at ffffffff8ceffe4727 [ffffbd13003d3ec0] smpboot_thread_fn at ffffffff8cf36a3028 [ffffbd13003d3ee8] kthread at ffffffff8cf2b39f29 [ffffbd13003d3f28] ret_from_fork at ffffffff8ce5fa6430 [ffffbd13003d3f50] ret_from_fork_asm at ffffffff8ce03cbb
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: protect link down work from execute after lgr freedlink down work may be scheduled before lgr freed but executeafter lgr freed, which may result in crash. So it is need tohold a reference before shedule link down work, and put thereference after work executed or canceled.The relevant crash call stack as follows: list_del corruption. prev->next should be ffffb638c9c0fe20, but was 0000000000000000 ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:51! invalid opcode: 0000 [#1] SMP NOPTI CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1 Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014 Workqueue: events smc_link_down_work [smc] RIP: 0010:__list_del_entry_valid.cold+0x31/0x47 RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086 RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000 RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38 R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002 R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0 FS: 0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: rwsem_down_write_slowpath+0x17e/0x470 smc_link_down_work+0x3c/0x60 [smc] process_one_work+0x1ac/0x350 worker_thread+0x49/0x2f0 ? rescuer_thread+0x360/0x360 kthread+0x118/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x1f/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conncount: Fully initialize struct nf_conncount_tuple in insert_tree()Since commit b36e4523d4d5 ("netfilter: nf_conncount: fix garbagecollection confirm race"), `cpu` and `jiffies32` were introduced tothe struct nf_conncount_tuple.The commit made nf_conncount_add() initialize `conn->cpu` and`conn->jiffies32` when allocating the struct.In contrast, count_tree() was not changed to initialize them.By commit 34848d5c896e ("netfilter: nf_conncount: Split insert andtraversal"), count_tree() was split and the relevant allocationcode now resides in insert_tree().Initialize `conn->cpu` and `conn->jiffies32` in insert_tree().BUG: KMSAN: uninit-value in find_or_evict net/netfilter/nf_conncount.c:117 [inline]BUG: KMSAN: uninit-value in __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143 find_or_evict net/netfilter/nf_conncount.c:117 [inline] __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143 count_tree net/netfilter/nf_conncount.c:438 [inline] nf_conncount_count+0x82f/0x1e80 net/netfilter/nf_conncount.c:521 connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72 __nft_match_eval net/netfilter/nft_compat.c:403 [inline] nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663 NF_HOOK_LIST include/linux/netfilter.h:350 [inline] ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633 ip_list_rcv+0x9ef/0xa40 net/ipv4/ip_input.c:669 __netif_receive_skb_list_ptype net/core/dev.c:5936 [inline] __netif_receive_skb_list_core+0x15c5/0x1670 net/core/dev.c:5983 __netif_receive_skb_list net/core/dev.c:6035 [inline] netif_receive_skb_list_internal+0x1085/0x1700 net/core/dev.c:6126 netif_receive_skb_list+0x5a/0x460 net/core/dev.c:6178 xdp_recv_frames net/bpf/test_run.c:280 [inline] xdp_test_run_batch net/bpf/test_run.c:361 [inline] bpf_test_run_xdp_live+0x2e86/0x3480 net/bpf/test_run.c:390 bpf_prog_test_run_xdp+0xf1d/0x1ae0 net/bpf/test_run.c:1316 bpf_prog_test_run+0x5e5/0xa30 kernel/bpf/syscall.c:4407 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5813 __do_sys_bpf kernel/bpf/syscall.c:5902 [inline] __se_sys_bpf kernel/bpf/syscall.c:5900 [inline] __ia32_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5900 ia32_sys_call+0x394d/0x4180 arch/x86/include/generated/asm/syscalls_32.h:358 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/common.c:387 do_fast_syscall_32+0x38/0x80 arch/x86/entry/common.c:412 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:450 entry_SYSENTER_compat_after_hwframe+0x84/0x8eUninit was created at: slab_post_alloc_hook mm/slub.c:4121 [inline] slab_alloc_node mm/slub.c:4164 [inline] kmem_cache_alloc_noprof+0x915/0xe10 mm/slub.c:4171 insert_tree net/netfilter/nf_conncount.c:372 [inline] count_tree net/netfilter/nf_conncount.c:450 [inline] nf_conncount_count+0x1415/0x1e80 net/netfilter/nf_conncount.c:521 connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72 __nft_match_eval net/netfilter/nft_compat.c:403 [inline] nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663 NF_HOOK_LIST include/linux/netfilter.h:350 [inline] ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633 ip_list_rcv+0x9ef/0xa40 net/ip---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 socketsWhen calling netlbl_conn_setattr(), addr->sa_family is usedto determine the function behavior. If sk is an IPv4 socket,but the connect function is called with an IPv6 address,the function calipso_sock_setattr() is triggered.Inside this function, the following code is executed:sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL;Since sk is an IPv4 socket, pinet6 is NULL, leading to anull pointer dereference.This patch fixes the issue by checking if inet6_sk(sk)returns a NULL pointer before accessing pinet6.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: A flaw was found in GLib. An integer overflow and buffer under-read occur when parsing a long invalid ISO 8601 timestamp with the g_date_time_new_from_iso8601() function.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libglib-2_0-0 > 0-0 (version in image is 2.70.5-150400.3.34.1).
-
Description: A vulnerability in the MIT Kerberos implementation allows GSSAPI-protected messages using RC4-HMAC-MD5 to be spoofed due to weaknesses in the MD5 checksum design. If RC4 is preferred over stronger encryption types, an attacker could exploit MD5 collisions to forge message integrity codes. This may lead to unauthorized message tampering.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- krb5 > 0-0 (version in image is 1.20.1-150500.3.17.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: don't restore null sk_state_changequeue->state_change is set as part of nvmet_tcp_set_queue_sock(), but ifthe TCP connection isn't established when nvmet_tcp_set_queue_sock() iscalled then queue->state_change isn't set and sock->sk->sk_state_changeisn't replaced.As such we don't need to restore sock->sk->sk_state_change ifqueue->state_change is NULL.This avoids NULL pointer dereferences such as this:[ 286.462026][ C0] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 286.462814][ C0] #PF: supervisor instruction fetch in kernel mode[ 286.463796][ C0] #PF: error_code(0x0010) - not-present page[ 286.464392][ C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0[ 286.465086][ C0] Oops: Oops: 0010 [#1] SMP KASAN PTI[ 286.465559][ C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary)[ 286.466393][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014[ 286.467147][ C0] RIP: 0010:0x0[ 286.467420][ C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6.[ 286.467977][ C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246[ 286.468425][ C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43[ 286.469019][ C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100[ 286.469545][ C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c[ 286.470072][ C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3[ 286.470585][ C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268[ 286.471070][ C0] FS: 00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000[ 286.471644][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 286.472543][ C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0[ 286.473500][ C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 286.474467][ C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400[ 286.475453][ C0] Call Trace:[ 286.476102][ C0] [ 286.476719][ C0] tcp_fin+0x2bb/0x440[ 286.477429][ C0] tcp_data_queue+0x190f/0x4e60[ 286.478174][ C0] ? __build_skb_around+0x234/0x330[ 286.478940][ C0] ? rcu_is_watching+0x11/0xb0[ 286.479659][ C0] ? __pfx_tcp_data_queue+0x10/0x10[ 286.480431][ C0] ? tcp_try_undo_loss+0x640/0x6c0[ 286.481196][ C0] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90[ 286.482046][ C0] ? kvm_clock_get_cycles+0x14/0x30[ 286.482769][ C0] ? ktime_get+0x66/0x150[ 286.483433][ C0] ? rcu_is_watching+0x11/0xb0[ 286.484146][ C0] tcp_rcv_established+0x6e4/0x2050[ 286.484857][ C0] ? rcu_is_watching+0x11/0xb0[ 286.485523][ C0] ? ipv4_dst_check+0x160/0x2b0[ 286.486203][ C0] ? __pfx_tcp_rcv_established+0x10/0x10[ 286.486917][ C0] ? lock_release+0x217/0x2c0[ 286.487595][ C0] tcp_v4_do_rcv+0x4d6/0x9b0[ 286.488279][ C0] tcp_v4_rcv+0x2af8/0x3e30[ 286.488904][ C0] ? raw_local_deliver+0x51b/0xad0[ 286.489551][ C0] ? rcu_is_watching+0x11/0xb0[ 286.490198][ C0] ? __pfx_tcp_v4_rcv+0x10/0x10[ 286.490813][ C0] ? __pfx_raw_local_deliver+0x10/0x10[ 286.491487][ C0] ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack][ 286.492275][ C0] ? rcu_is_watching+0x11/0xb0[ 286.492900][ C0] ip_protocol_deliver_rcu+0x8f/0x370[ 286.493579][ C0] ip_local_deliver_finish+0x297/0x420[ 286.494268][ C0] ip_local_deliver+0x168/0x430[ 286.494867][ C0] ? __pfx_ip_local_deliver+0x10/0x10[ 286.495498][ C0] ? __pfx_ip_local_deliver_finish+0x10/0x10[ 286.496204][ C0] ? ip_rcv_finish_core+0x19a/0x1f20[ 286.496806][ C0] ? lock_release+0x217/0x2c0[ 286.497414][ C0] ip_rcv+0x455/0x6e0[ 286.497945][ C0] ? __pfx_ip_rcv+0x10/0x10[ ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:inet: frags: flush pending skbs in fqdir_pre_exit()We have been seeing occasional deadlocks on pernet_ops_rwsem sinceSeptember in NIPA. The stuck task was usually modprobe (often loadinga driver like ipvlan), trying to take the lock as a Writer.lockdep does not track readers for rwsems so the read wasn't obviousfrom the reports.On closer inspection the Reader holding the lock was conntrack loopingforever in nf_conntrack_cleanup_net_list(). Based on past experiencewith occasional NIPA crashes I looked thru the tests which run beforethe crash and noticed that the crash follows ip_defrag.sh. An immediatered flag. Scouring thru (de)fragmentation queues reveals skbs sittingaround, holding conntrack references.The problem is that since conntrack depends on nf_defrag_ipv6,nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first itsnetns exit hooks run _after_ conntrack's netns exit hook.Flush all fragment queue SKBs during fqdir_pre_exit() to releaseconntrack references before conntrack cleanup runs. Also flushthe queues in timer expiry handlers when they discover fqdir->deadis set, in case packet sneaks in while we're running the pre_exitflush.The commit under Fixes is not exactly the culprit, but I thinkpreviously the timer firing would eventually unblock the spinningconntrack.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/hsr: fix NULL pointer dereference in prp_get_untagged_frame()prp_get_untagged_frame() calls __pskb_copy() to create frame->skb_stdbut doesn't check if the allocation failed. If __pskb_copy() returnsNULL, skb_clone() is called with a NULL pointer, causing a crash:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]CPU: 0 UID: 0 PID: 5625 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:skb_clone+0xd7/0x3a0 net/core/skbuff.c:2041Code: 03 42 80 3c 20 00 74 08 4c 89 f7 e8 23 29 05 f9 49 83 3e 00 0f 85 a0 01 00 00 e8 94 dd 9d f8 48 8d 6b 7e 49 89 ee 49 c1 ee 03 <43> 0f b6 04 26 84 c0 0f 85 d1 01 00 00 44 0f b6 7d 00 41 83 e7 0cRSP: 0018:ffffc9000d00f200 EFLAGS: 00010207RAX: ffffffff892235a1 RBX: 0000000000000000 RCX: ffff88803372a480RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000000RBP: 000000000000007e R08: ffffffff8f7d0f77 R09: 1ffffffff1efa1eeR10: dffffc0000000000 R11: fffffbfff1efa1ef R12: dffffc0000000000R13: 0000000000000820 R14: 000000000000000f R15: ffff88805144cc00FS: 0000555557f6d500(0000) GS:ffff88808d72f000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000555581d35808 CR3: 000000005040e000 CR4: 0000000000352ef0Call Trace: hsr_forward_do net/hsr/hsr_forward.c:-1 [inline] hsr_forward_skb+0x1013/0x2860 net/hsr/hsr_forward.c:741 hsr_handle_frame+0x6ce/0xa70 net/hsr/hsr_slave.c:84 __netif_receive_skb_core+0x10b9/0x4380 net/core/dev.c:5966 __netif_receive_skb_one_core net/core/dev.c:6077 [inline] __netif_receive_skb+0x72/0x380 net/core/dev.c:6192 netif_receive_skb_internal net/core/dev.c:6278 [inline] netif_receive_skb+0x1cb/0x790 net/core/dev.c:6337 tun_rx_batched+0x1b9/0x730 drivers/net/tun.c:1485 tun_get_user+0x2b65/0x3e90 drivers/net/tun.c:1953 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f0449f8e1ffCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 f9 92 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 4c 93 02 00 48RSP: 002b:00007ffd7ad94c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007f044a1e5fa0 RCX: 00007f0449f8e1ffRDX: 000000000000003e RSI: 0000200000000500 RDI: 00000000000000c8RBP: 00007ffd7ad94d20 R08: 0000000000000000 R09: 0000000000000000R10: 000000000000003e R11: 0000000000000293 R12: 0000000000000001R13: 00007f044a1e5fa0 R14: 00007f044a1e5fa0 R15: 0000000000000003 Add a NULL check immediately after __pskb_copy() to handle allocationfailures gracefully.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In GnuPG through 2.4.8, if a signed message has \f at the end of a plaintext line, an adversary can construct a modified message that places additional text after the signed material, such that signature verification of the modified message succeeds (although an "invalid armor" message is printed during verification). This is related to use of \f as a marker to denote truncation of a long plaintext line.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- gpg2 > 0-0 (version in image is 2.2.27-150300.3.19.1).
-
Description: A flaw was found in libxml2, an XML parsing library. This uncontrolled recursion vulnerability occurs in the xmlCatalogXMLResolveURI function when an XML catalog contains a delegate URI entry that references itself. A remote attacker could exploit this configuration-dependent issue by providing a specially crafted XML catalog, leading to infinite recursion and call stack exhaustion. This ultimately results in a segmentation fault, causing a Denial of Service (DoS) by crashing affected applications.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libxml2-2 > 0-0 (version in image is 2.10.3-150500.5.38.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmitteql_master_xmit() calls netdev_start_xmit(skb, slave) to transmitthrough slave devices, but does not update skb->dev to the slave devicebeforehand.When a gretap tunnel is a TEQL slave, the transmit path reachesiptunnel_xmit() which saves dev = skb->dev (still pointing to teql0master) and later calls iptunnel_xmit_stats(dev, pkt_len). Thisfunction does: get_cpu_ptr(dev->tstats)Since teql_master_setup() does not set dev->pcpu_stat_type toNETDEV_PCPU_STAT_TSTATS, the core network stack never allocates tstatsfor teql0, so dev->tstats is NULL. get_cpu_ptr(NULL) computesNULL + __per_cpu_offset[cpu], resulting in a page fault. BUG: unable to handle page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89) Call Trace: ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) __gre_xmit (net/ipv4/ip_gre.c:478) gre_tap_xmit (net/ipv4/ip_gre.c:779) teql_master_xmit (net/sched/sch_teql.c:319) 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) neigh_direct_output (net/core/neighbour.c:1660) ip_finish_output2 (net/ipv4/ip_output.c:237) __ip_finish_output.part.0 (net/ipv4/ip_output.c:315) ip_mc_output (net/ipv4/ip_output.c:369) ip_send_skb (net/ipv4/ip_output.c:1508) udp_send_skb (net/ipv4/udp.c:1195) udp_sendmsg (net/ipv4/udp.c:1485) inet_sendmsg (net/ipv4/af_inet.c:859) __sys_sendto (net/socket.c:2206)Fix this by setting skb->dev = slave before callingnetdev_start_xmit(), so that tunnel xmit functions see the correctslave device with properly allocated tstats.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:icmp: fix NULL pointer dereference in icmp_tag_validation()icmp_tag_validation() unconditionally dereferences the result ofrcu_dereference(inet_protos[proto]) without checking for NULL.The inet_protos[] array is sparse -- only about 15 of 256 protocolnumbers have registered handlers. When ip_no_pmtu_disc is set to 3(hardened PMTU mode) and the kernel receives an ICMP FragmentationNeeded error with a quoted inner IP header containing an unregisteredprotocol number, the NULL dereference causes a kernel panic insoftirq context. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143) Call Trace: icmp_rcv (net/ipv4/icmp.c:1527) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207) ip_local_deliver_finish (net/ipv4/ip_input.c:242) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) __netif_receive_skb_one_core (net/core/dev.c:6164) process_backlog (net/core/dev.c:6628) handle_softirqs (kernel/softirq.c:561) Add a NULL check before accessing icmp_strict_tag_validation. If theprotocol has no registered handler, return false since it cannotperform strict tag validation.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- krb5 > 0-0 (version in image is 1.20.1-150500.3.17.1).
-
Description: In 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 == 15.5 (version in image is 15.5-150500.61.4.1).
- krb5 > 0-0 (version in image is 1.20.1-150500.3.17.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix divide-by-zero in tipc_sk_filter_connect()A user can set conn_timeout to any value viasetsockopt(TIPC_CONN_TIMEOUT), including values less than 4. When aSYN is rejected with TIPC_ERR_OVERLOAD and the retry path intipc_sk_filter_connect() executes: delay %= (tsk->conn_timeout / 4);If conn_timeout is in the range [0, 3], the integer division yields 0,and the modulo operation triggers a divide-by-zero exception, causing akernel oops/panic.Fix this by clamping conn_timeout to a minimum of 4 at the point of usein tipc_sk_filter_connect().Oops: divide error: 0000 [#1] SMP KASAN NOPTICPU: 0 UID: 0 PID: 119 Comm: poc-F144 Not tainted 7.0.0-rc2+RIP: 0010:tipc_sk_filter_rcv (net/tipc/socket.c:2236 net/tipc/socket.c:2362)Call Trace: tipc_sk_backlog_rcv (include/linux/instrumented.h:82 include/linux/atomic/atomic-instrumented.h:32 include/net/sock.h:2357 net/tipc/socket.c:2406) __release_sock (include/net/sock.h:1185 net/core/sock.c:3213) release_sock (net/core/sock.c:3797) tipc_connect (net/tipc/socket.c:2570) __sys_connect (include/linux/file.h:62 include/linux/file.h:83 net/socket.c:2098)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: Unknown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.56.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- glibc > 0-0 (version in image is 2.31-150300.98.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- curl > 0-0 (version in image is 8.14.1-150400.5.83.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:binder: fix UAF of ref->proc caused by race conditionA transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment thereference for a node. In this case, the target proc normally releasesthe failed reference upon close as expected. However, if the target isdying in parallel the call will race with binder_deferred_release(), sothe target could have released all of its references by now leaving thecleanup of the new failed reference unhandled.The transaction then ends and the target proc gets released making theref->proc now a dangling pointer. Later on, ref->node is closed and weattempt to take spin_lock(&ref->proc->inner_lock), which leads to theuse-after-free bug reported below. Let's fix this by cleaning up thefailed reference on the spot instead of relying on the target to do so. ================================================================== BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150 Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 #10 Hardware name: linux,dummy-virt (DT) Workqueue: events binder_deferred_func Call trace: dump_backtrace.part.0+0x1d0/0x1e0 show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 print_report+0x2e4/0x61c kasan_report+0xa4/0x110 kasan_check_range+0xfc/0x1a4 __kasan_check_write+0x3c/0x50 _raw_spin_lock+0xa8/0x150 binder_deferred_func+0x5e0/0x9b0 process_one_work+0x38c/0x5f0 worker_thread+0x9c/0x694 kthread+0x188/0x190 ret_from_fork+0x10/0x20
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_transThere is a kernel API ntb_mw_clear_trans() would pass 0 to both addr andsize. This would make xlate_pos negative.[ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000[ 23.734158] ================================================================================[ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7[ 23.734418] shift exponent -1 is negativeEnsuring xlate_pos is a positive or zero before BIT.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-crypto: make blk_crypto_evict_key() more robustIf blk_crypto_evict_key() sees that the key is still in-use (due to abug) or that ->keyslot_evict failed, it currently just returns whileleaving the key linked into the keyslot management structures.However, blk_crypto_evict_key() is only called in contexts such as inodeeviction where failure is not an option. So actually the callerproceeds with freeing the blk_crypto_key regardless of the return valueof blk_crypto_evict_key().These two assumptions don't match, and the result is that there can be ause-after-free in blk_crypto_reprogram_all_keys() after one of theseerrors occurs. (Note, these errors *shouldn't* happen; we're justtalking about what happens if they do anyway.)Fix this by making blk_crypto_evict_key() unlink the key from thekeyslot management structures even on failure.Also improve some comments.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: dlm: fix use after free in midcomms commitWhile working on processing dlm message in softirq context I experiencedthe following KASAN use-after-free warning:[ 151.760477] ==================================================================[ 151.761803] BUG: KASAN: use-after-free in dlm_midcomms_commit_mhandle+0x19d/0x4b0[ 151.763414] Read of size 4 at addr ffff88811a980c60 by task lock_torture/1347[ 151.765284] CPU: 7 PID: 1347 Comm: lock_torture Not tainted 6.1.0-rc4+ #2828[ 151.766778] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+16134+e5908aa2 04/01/2014[ 151.768726] Call Trace:[ 151.769277] [ 151.769748] dump_stack_lvl+0x5b/0x86[ 151.770556] print_report+0x180/0x4c8[ 151.771378] ? kasan_complete_mode_report_info+0x7c/0x1e0[ 151.772241] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0[ 151.773069] kasan_report+0x93/0x1a0[ 151.773668] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0[ 151.774514] __asan_load4+0x7e/0xa0[ 151.775089] dlm_midcomms_commit_mhandle+0x19d/0x4b0[ 151.775890] ? create_message.isra.29.constprop.64+0x57/0xc0[ 151.776770] send_common+0x19f/0x1b0[ 151.777342] ? remove_from_waiters+0x60/0x60[ 151.778017] ? lock_downgrade+0x410/0x410[ 151.778648] ? __this_cpu_preempt_check+0x13/0x20[ 151.779421] ? rcu_lockdep_current_cpu_online+0x88/0xc0[ 151.780292] _convert_lock+0x46/0x150[ 151.780893] convert_lock+0x7b/0xc0[ 151.781459] dlm_lock+0x3ac/0x580[ 151.781993] ? 0xffffffffc0540000[ 151.782522] ? torture_stop+0x120/0x120 [dlm_locktorture][ 151.783379] ? dlm_scan_rsbs+0xa70/0xa70[ 151.784003] ? preempt_count_sub+0xd6/0x130[ 151.784661] ? is_module_address+0x47/0x70[ 151.785309] ? torture_stop+0x120/0x120 [dlm_locktorture][ 151.786166] ? 0xffffffffc0540000[ 151.786693] ? lockdep_init_map_type+0xc3/0x360[ 151.787414] ? 0xffffffffc0540000[ 151.787947] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture][ 151.789004] ? torture_stop+0x120/0x120 [dlm_locktorture][ 151.789858] ? 0xffffffffc0540000[ 151.790392] ? lock_torture_cleanup+0x20/0x20 [dlm_locktorture][ 151.791347] ? delay_tsc+0x94/0xc0[ 151.791898] torture_ex_iter+0xc3/0xea [dlm_locktorture][ 151.792735] ? torture_start+0x30/0x30 [dlm_locktorture][ 151.793606] lock_torture+0x177/0x270 [dlm_locktorture][ 151.794448] ? torture_dlm_lock_sync.isra.3+0x150/0x150 [dlm_locktorture][ 151.795539] ? lock_torture_stats+0x80/0x80 [dlm_locktorture][ 151.796476] ? do_raw_spin_lock+0x11e/0x1e0[ 151.797152] ? mark_held_locks+0x34/0xb0[ 151.797784] ? _raw_spin_unlock_irqrestore+0x30/0x70[ 151.798581] ? __kthread_parkme+0x79/0x110[ 151.799246] ? trace_preempt_on+0x2a/0xf0[ 151.799902] ? __kthread_parkme+0x79/0x110[ 151.800579] ? preempt_count_sub+0xd6/0x130[ 151.801271] ? __kasan_check_read+0x11/0x20[ 151.801963] ? __kthread_parkme+0xec/0x110[ 151.802630] ? lock_torture_stats+0x80/0x80 [dlm_locktorture][ 151.803569] kthread+0x192/0x1d0[ 151.804104] ? kthread_complete_and_exit+0x30/0x30[ 151.804881] ret_from_fork+0x1f/0x30[ 151.805480] [ 151.806111] Allocated by task 1347:[ 151.806681] kasan_save_stack+0x26/0x50[ 151.807308] kasan_set_track+0x25/0x30[ 151.807920] kasan_save_alloc_info+0x1e/0x30[ 151.808609] __kasan_slab_alloc+0x63/0x80[ 151.809263] kmem_cache_alloc+0x1ad/0x830[ 151.809916] dlm_allocate_mhandle+0x17/0x20[ 151.810590] dlm_midcomms_get_mhandle+0x96/0x260[ 151.811344] _create_message+0x95/0x180[ 151.811994] create_message.isra.29.constprop.64+0x57/0xc0[ 151.812880] send_common+0x129/0x1b0[ 151.813467] _convert_lock+0x46/0x150[ 151.814074] convert_lock+0x7b/0xc0[ 151.814648] dlm_lock+0x3ac/0x580[ 151.815199] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture][ 151.816258] torture_ex_iter+0xc3/0xea [dlm_locktorture][ 151.817129] lock_t---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:riscv: ftrace: Fixup panic by disabling preemptionIn RISCV, we must use an AUIPC + JALR pair to encode an immediate,forming a jump that jumps to an address over 4K. This may cause errorsif we want to enable kernel preemption and remove dependency frompatching code with stop_machine(). For example, if a task was switchedout on auipc. And, if we changed the ftrace function before it wasswitched back, then it would jump to an address that has updated 11:0bits mixing with previous XLEN:12 part.p: patched area performed by dynamic ftraceftrace_prologue:p| REG_S ra, -SZREG(sp)p| auipc ra, 0x? ------------> preempted ... change ftrace function ...p| jalr -?(ra) <------------- switched backp| REG_L ra, -SZREG(sp)func: xxx ret
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: stricter state check in mptcp_workerAs reported by Christoph, the mptcp protocol can run theworker when the relevant msk socket is in an unexpected state:connect()// incoming reset + fastclose// the mptcp worker is scheduledmptcp_disconnect()// msk is now CLOSEDlisten()mptcp_worker()Leading to the following splat:divide error: 0000 [#1] PREEMPT SMPCPU: 1 PID: 21 Comm: kworker/1:0 Not tainted 6.3.0-rc1-gde5e8fd0123c #11Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014Workqueue: events mptcp_workerRIP: 0010:__tcp_select_window+0x22c/0x4b0 net/ipv4/tcp_output.c:3018RSP: 0018:ffffc900000b3c98 EFLAGS: 00010293RAX: 000000000000ffd7 RBX: 000000000000ffd7 RCX: 0000000000000000RDX: 0000000000000000 RSI: ffffffff8214ce97 RDI: 0000000000000004RBP: 000000000000ffd7 R08: 0000000000000004 R09: 0000000000010000R10: 000000000000ffd7 R11: ffff888005afa148 R12: 000000000000ffd7R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000405270 CR3: 000000003011e006 CR4: 0000000000370ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tcp_select_window net/ipv4/tcp_output.c:262 [inline] __tcp_transmit_skb+0x356/0x1280 net/ipv4/tcp_output.c:1345 tcp_transmit_skb net/ipv4/tcp_output.c:1417 [inline] tcp_send_active_reset+0x13e/0x320 net/ipv4/tcp_output.c:3459 mptcp_check_fastclose net/mptcp/protocol.c:2530 [inline] mptcp_worker+0x6c7/0x800 net/mptcp/protocol.c:2705 process_one_work+0x3bd/0x950 kernel/workqueue.c:2390 worker_thread+0x5b/0x610 kernel/workqueue.c:2537 kthread+0x138/0x170 kernel/kthread.c:376 ret_from_fork+0x2c/0x50 arch/x86/entry/entry_64.S:308 This change addresses the issue explicitly checking for bad statesbefore running the mptcp worker.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Address KCSAN report on bpf_lru_listKCSAN reported a data-race when accessing node->ref.Although node->ref does not have to be accurate,take this chance to use a more common READ_ONCE() and WRITE_ONCE()pattern instead of data_race().There is an existing bpf_lru_node_is_ref() and bpf_lru_node_set_ref().This patch also adds bpf_lru_node_clear_ref() to do theWRITE_ONCE(node->ref, 0) also.==================================================================BUG: KCSAN: data-race in __bpf_lru_list_rotate / __htab_lru_percpu_map_update_elemwrite to 0xffff888137038deb of 1 bytes by task 11240 on cpu 1:__bpf_lru_node_move kernel/bpf/bpf_lru_list.c:113 [inline]__bpf_lru_list_rotate_active kernel/bpf/bpf_lru_list.c:149 [inline]__bpf_lru_list_rotate+0x1bf/0x750 kernel/bpf/bpf_lru_list.c:240bpf_lru_list_pop_free_to_local kernel/bpf/bpf_lru_list.c:329 [inline]bpf_common_lru_pop_free kernel/bpf/bpf_lru_list.c:447 [inline]bpf_lru_pop_free+0x638/0xe20 kernel/bpf/bpf_lru_list.c:499prealloc_lru_pop kernel/bpf/hashtab.c:290 [inline]__htab_lru_percpu_map_update_elem+0xe7/0x820 kernel/bpf/hashtab.c:1316bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534__sys_bpf+0x338/0x810__do_sys_bpf kernel/bpf/syscall.c:5096 [inline]__se_sys_bpf kernel/bpf/syscall.c:5094 [inline]__x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdread to 0xffff888137038deb of 1 bytes by task 11241 on cpu 0:bpf_lru_node_set_ref kernel/bpf/bpf_lru_list.h:70 [inline]__htab_lru_percpu_map_update_elem+0x2f1/0x820 kernel/bpf/hashtab.c:1332bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534__sys_bpf+0x338/0x810__do_sys_bpf kernel/bpf/syscall.c:5096 [inline]__se_sys_bpf kernel/bpf/syscall.c:5094 [inline]__x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x01 -> 0x00Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 11241 Comm: syz-executor.3 Not tainted 6.3.0-rc7-syzkaller-00136-g6a66fdd29ea1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023==================================================================
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()Under certain kernel configurations when building with Clang/LLVM, thecompiler does not generate a return or jump as the terminatorinstruction for ip_vs_protocol_init(), triggering the following objtoolwarning during build time: vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6()At runtime, this either causes an oops when trying to load the ipvsmodule or a boot-time panic if ipvs is built-in. This same issue hasbeen reported by the Intel kernel test robot previously.Digging deeper into both LLVM and the kernel code reveals this to be aundefined behavior problem. ip_vs_protocol_init() uses a on-stack bufferof 64 chars to store the registered protocol names and leaves ituninitialized after definition. The function calls strnlen() whenconcatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCEstrnlen() performs an extra step to check whether the last byte of theinput char buffer is a null character (commit 3009f891bb9f ("fortify:Allow strlen() and strnlen() to pass compile-time known lengths")).This, together with possibly other configurations, cause the followingIR to be generated: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section ".init.text" align 16 !kcfi_type !29 { %1 = alloca [64 x i8], align 16 ... 14: ; preds = %11 %15 = getelementptr inbounds i8, ptr %1, i64 63 %16 = load i8, ptr %15, align 1 %17 = tail call i1 @llvm.is.constant.i8(i8 %16) %18 = icmp eq i8 %16, 0 %19 = select i1 %17, i1 %18, i1 false br i1 %19, label %20, label %23 20: ; preds = %14 %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23 ... 23: ; preds = %14, %11, %20 %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24 ... }The above code calculates the address of the last char in the buffer(value %15) and then loads from it (value %16). Because the buffer isnever initialized, the LLVM GVN pass marks value %16 as undefined: %13 = getelementptr inbounds i8, ptr %1, i64 63 br i1 undef, label %14, label %17This gives later passes (SCCP, in particular) more DCE opportunities bypropagating the undef value further, and eventually removes everythingafter the load on the uninitialized stack location: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section ".init.text" align 16 !kcfi_type !11 { %1 = alloca [64 x i8], align 16 ... 12: ; preds = %11 %13 = getelementptr inbounds i8, ptr %1, i64 63 unreachable }In this way, the generated native code will just fall through to thenext function, as LLVM does not generate any code for the unreachable IRinstruction and leaves the function without a terminator.Zero the on-stack buffer to avoid this possible UB.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix slab-use-after-free in hdcpThe HDCP code in amdgpu_dm_hdcp.c copies pointers to amdgpu_dm_connectorobjects without incrementing the kref reference counts. When using aUSB-C dock, and the dock is unplugged, the correspondingamdgpu_dm_connector objects are freed, creating dangling pointers in theHDCP code. When the dock is plugged back, the dangling pointers aredereferenced, resulting in a slab-use-after-free:[ 66.775837] BUG: KASAN: slab-use-after-free in event_property_validate+0x42f/0x6c0 [amdgpu][ 66.776171] Read of size 4 at addr ffff888127804120 by task kworker/0:1/10[ 66.776179] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.14.0-rc7-00180-g54505f727a38-dirty #233[ 66.776183] Hardware name: HP HP Pavilion Aero Laptop 13-be0xxx/8916, BIOS F.17 12/18/2024[ 66.776186] Workqueue: events event_property_validate [amdgpu][ 66.776494] Call Trace:[ 66.776496] [ 66.776497] dump_stack_lvl+0x70/0xa0[ 66.776504] print_report+0x175/0x555[ 66.776507] ? __virt_addr_valid+0x243/0x450[ 66.776510] ? kasan_complete_mode_report_info+0x66/0x1c0[ 66.776515] kasan_report+0xeb/0x1c0[ 66.776518] ? event_property_validate+0x42f/0x6c0 [amdgpu][ 66.776819] ? event_property_validate+0x42f/0x6c0 [amdgpu][ 66.777121] __asan_report_load4_noabort+0x14/0x20[ 66.777124] event_property_validate+0x42f/0x6c0 [amdgpu][ 66.777342] ? __lock_acquire+0x6b40/0x6b40[ 66.777347] ? enable_assr+0x250/0x250 [amdgpu][ 66.777571] process_one_work+0x86b/0x1510[ 66.777575] ? pwq_dec_nr_in_flight+0xcf0/0xcf0[ 66.777578] ? assign_work+0x16b/0x280[ 66.777580] ? lock_is_held_type+0xa3/0x130[ 66.777583] worker_thread+0x5c0/0xfa0[ 66.777587] ? process_one_work+0x1510/0x1510[ 66.777588] kthread+0x3a2/0x840[ 66.777591] ? kthread_is_per_cpu+0xd0/0xd0[ 66.777594] ? trace_hardirqs_on+0x4f/0x60[ 66.777597] ? _raw_spin_unlock_irq+0x27/0x60[ 66.777599] ? calculate_sigpending+0x77/0xa0[ 66.777602] ? kthread_is_per_cpu+0xd0/0xd0[ 66.777605] ret_from_fork+0x40/0x90[ 66.777607] ? kthread_is_per_cpu+0xd0/0xd0[ 66.777609] ret_from_fork_asm+0x11/0x20[ 66.777614] [ 66.777643] Allocated by task 10:[ 66.777646] kasan_save_stack+0x39/0x60[ 66.777649] kasan_save_track+0x14/0x40[ 66.777652] kasan_save_alloc_info+0x37/0x50[ 66.777655] __kasan_kmalloc+0xbb/0xc0[ 66.777658] __kmalloc_cache_noprof+0x1c8/0x4b0[ 66.777661] dm_dp_add_mst_connector+0xdd/0x5c0 [amdgpu][ 66.777880] drm_dp_mst_port_add_connector+0x47e/0x770 [drm_display_helper][ 66.777892] drm_dp_send_link_address+0x1554/0x2bf0 [drm_display_helper][ 66.777901] drm_dp_check_and_send_link_address+0x187/0x1f0 [drm_display_helper][ 66.777909] drm_dp_mst_link_probe_work+0x2b8/0x410 [drm_display_helper][ 66.777917] process_one_work+0x86b/0x1510[ 66.777919] worker_thread+0x5c0/0xfa0[ 66.777922] kthread+0x3a2/0x840[ 66.777925] ret_from_fork+0x40/0x90[ 66.777927] ret_from_fork_asm+0x11/0x20[ 66.777932] Freed by task 1713:[ 66.777935] kasan_save_stack+0x39/0x60[ 66.777938] kasan_save_track+0x14/0x40[ 66.777940] kasan_save_free_info+0x3b/0x60[ 66.777944] __kasan_slab_free+0x52/0x70[ 66.777946] kfree+0x13f/0x4b0[ 66.777949] dm_dp_mst_connector_destroy+0xfa/0x150 [amdgpu][ 66.778179] drm_connector_free+0x7d/0xb0[ 66.778184] drm_mode_object_put.part.0+0xee/0x160[ 66.778188] drm_mode_object_put+0x37/0x50[ 66.778191] drm_atomic_state_default_clear+0x220/0xd60[ 66.778194] __drm_atomic_state_free+0x16e/0x2a0[ 66.778197] drm_mode_atomic_ioctl+0x15ed/0x2ba0[ 66.778200] drm_ioctl_kernel+0x17a/0x310[ 66.778203] drm_ioctl+0x584/0xd10[ 66.778206] amdgpu_drm_ioctl+0xd2/0x1c0 [amdgpu][ 66.778375] __x64_sys_ioctl+0x139/0x1a0[ 66.778378] x64_sys_call+0xee7/0xfb0[ 66.778381] ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: k3-udma: Add missing lockingRecent kernels complain about a missing lock in k3-udma.c when the lockvalidator is enabled:[ 4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238[ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28[ 4.144867] Hardware name: pp-v12 (DT)[ 4.148648] Workqueue: events udma_check_tx_completion[ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 4.160834] pc : udma_start.isra.0+0x34/0x238[ 4.165227] lr : udma_start.isra.0+0x30/0x238[ 4.169618] sp : ffffffc083cabcf0[ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005[ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000[ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670[ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030[ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048[ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001[ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68[ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8[ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000[ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000[ 4.244986] Call trace:[ 4.247463] udma_start.isra.0+0x34/0x238[ 4.251509] udma_check_tx_completion+0xd0/0xdc[ 4.256076] process_one_work+0x244/0x3fc[ 4.260129] process_scheduled_works+0x6c/0x74[ 4.264610] worker_thread+0x150/0x1dc[ 4.268398] kthread+0xd8/0xe8[ 4.271492] ret_from_fork+0x10/0x20[ 4.275107] irq event stamp: 220[ 4.278363] hardirqs last enabled at (219): [] _raw_spin_unlock_irq+0x38/0x50[ 4.287183] hardirqs last disabled at (220): [] el1_dbg+0x24/0x50[ 4.294879] softirqs last enabled at (182): [] handle_softirqs+0x1c0/0x3cc[ 4.303437] softirqs last disabled at (177): [] __do_softirq+0x1c/0x28[ 4.311559] ---[ end trace 0000000000000000 ]---This commit adds the missing locking.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookieThe IOMMU translation for MSI message addresses has been a 2-step process,separated in time: 1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address is stored in the MSI descriptor when an MSI interrupt is allocated. 2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a translated message address.This has an inherent lifetime problem for the pointer stored in the cookiethat must remain valid between the two steps. However, there is no lockingat the irq layer that helps protect the lifetime. Today, this works underthe assumption that the iommu domain is not changed while MSI interruptsbeing programmed. This is true for normal DMA API users within the kernel,as the iommu domain is attached before the driver is probed and cannot bechanged while a driver is attached.Classic VFIO type1 also prevented changing the iommu domain while VFIO wasrunning as it does not support changing the "container" after starting up.However, iommufd has improved this so that the iommu domain can be changedduring VFIO operation. This potentially allows userspace to directly raceVFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) andVFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).This potentially causes both the cookie pointer and the unlocked call toiommu_get_domain_for_dev() on the MSI translation path to become UAFs.Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVAaddress is already known during iommu_dma_prepare_msi() and cannot change.Thus, it can simply be stored as an integer in the MSI descriptor.The other UAF related to iommu_get_domain_for_dev() will be addressed inpatch "iommu: Make iommu_dma_prepare_msi() into a generic operation" byusing the IOMMU group mutex.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Protect mgmt_pending list with its own lockThis uses a mutex to protect from concurrent access of mgmt_pendinglist which can cause crashes like:==================================================================BUG: KASAN: slab-use-after-free in hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91Read of size 2 at addr ffff0000c48885b2 by task syz.4.334/7318CPU: 0 UID: 0 PID: 7318 Comm: syz.4.334 Not tainted 6.15.0-rc7-syzkaller-g187899f4124a #0 PREEMPTHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_address_description+0xa8/0x254 mm/kasan/report.c:408 print_report+0x68/0x84 mm/kasan/report.c:521 kasan_report+0xb0/0x110 mm/kasan/report.c:634 __asan_report_load2_noabort+0x20/0x2c mm/kasan/report_generic.c:379 hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 mgmt_pending_find+0x7c/0x140 net/bluetooth/mgmt_util.c:223 pending_find net/bluetooth/mgmt.c:947 [inline] remove_adv_monitor+0x44/0x1a4 net/bluetooth/mgmt.c:5445 hci_mgmt_cmd+0x780/0xc00 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x544/0xbb0 net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x25c/0x378 net/socket.c:1131 new_sync_write fs/read_write.c:591 [inline] vfs_write+0x62c/0x97c fs/read_write.c:684 ksys_write+0x120/0x210 fs/read_write.c:736 __do_sys_write fs/read_write.c:747 [inline] __se_sys_write fs/read_write.c:744 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:744 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600Allocated by task 7037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x54 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x9c/0xb4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4327 [inline] __kmalloc_noprof+0x2fc/0x4c8 mm/slub.c:4339 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xc4/0x1f0 net/core/sock.c:2198 sk_alloc+0x44/0x3ac net/core/sock.c:2254 bt_sock_alloc+0x4c/0x300 net/bluetooth/af_bluetooth.c:148 hci_sock_create+0xa8/0x194 net/bluetooth/hci_sock.c:2202 bt_sock_create+0x14c/0x24c net/bluetooth/af_bluetooth.c:132 __sock_create+0x43c/0x91c net/socket.c:1541 sock_create net/socket.c:1599 [inline] __sys_socket_create net/socket.c:1636 [inline] __sys_socket+0xd4/0x1c0 net/socket.c:1683 __do_sys_socket net/socket.c:1697 [inline] __se_sys_socket net/socket.c:1695 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1695 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600Freed by task 6607: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_free_info+0x58/0x70 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x68/0x88 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Avoid using sk_socket after free when sendingThe sk->sk_socket is not locked or referenced in backlog thread, andduring the call to skb_send_sock(), there is a race condition withthe release of sk_socket. All types of sockets(tcp/udp/unix/vsock)will be affected.Race conditions:'''CPU0 CPU1backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here'''The ref of psock become 0 after sock_map_close() executed.'''void sock_map_close(){ ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Control jumps here via goto ... cancel_delayed_work_sync(&psock->work); <=== not executed sk_psock_put(sk, psock); ...}'''Based on the fact that we already wait for the workqueue to finish insock_map_close() if psock is held, we simply increase the psockreference count to avoid race conditions.With this patch, if the backlog thread is running, sock_map_close() willwait for the backlog thread to complete and cancel all pending work.If no backlog running, any pending work that hasn't started by then willfail when invoked by sk_psock_get(), as the psock reference count havebeen zeroed, and sk_psock_drop() will cancel all jobs viacancel_delayed_work_sync().In summary, we require synchronization to coordinate the backlog threadand close() thread.The panic I catched:'''Workqueue: events sk_psock_backlogRIP: 0010:sock_sendmsg+0x21d/0x440RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001...Call Trace: ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80...'''
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: validate AG parameters in dbMount() to prevent crashesValidate db_agheight, db_agwidth, and db_agstart in dbMount to catchcorrupted metadata early and avoid undefined behavior in dbAllocAG.Limits are derived from L2LPERCTL, LPERCTL/MAXAG, and CTLTREESIZE:- agheight: 0 to L2LPERCTL/2 (0 to 5) ensures shift (L2LPERCTL - 2*agheight) >= 0.- agwidth: 1 to min(LPERCTL/MAXAG, 2^(L2LPERCTL - 2*agheight)) ensures agperlev >= 1. - Ranges: 1-8 (agheight 0-3), 1-4 (agheight 4), 1 (agheight 5). - LPERCTL/MAXAG = 1024/128 = 8 limits leaves per AG; 2^(10 - 2*agheight) prevents division to 0.- agstart: 0 to CTLTREESIZE-1 - agwidth*(MAXAG-1) keeps ti within stree (size 1365). - Ranges: 0-1237 (agwidth 1), 0-348 (agwidth 8).UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:1400:9shift exponent -335544310 is negativeCPU: 0 UID: 0 PID: 5822 Comm: syz-executor130 Not tainted 6.14.0-rc5-syzkaller #0Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468 dbAllocAG+0x1087/0x10b0 fs/jfs/jfs_dmap.c:1400 dbDiscardAG+0x352/0xa20 fs/jfs/jfs_dmap.c:1613 jfs_ioc_trim+0x45a/0x6b0 fs/jfs/jfs_discard.c:105 jfs_ioctl+0x2cd/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fFound by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: check return result of sb_min_blocksizeSyzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug.Syzkaller forks multiple processes which after mounting the Squashfsfilesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000). Now if this ioctl occurs at the same time another process is in theprocess of mounting a Squashfs filesystem on /dev/loop0, the failureoccurs. When this happens the following code in squashfs_fill_super()fails.----msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE);msblk->devblksize_log2 = ffz(~msblk->devblksize);----sb_min_blocksize() returns 0, which means msblk->devblksize is set to 0.As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2is set to 64.This subsequently causes theUBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36shift exponent 64 is too large for 64-bit type 'u64' (aka'unsigned long long')This commit adds a check for a 0 return by sb_min_blocksize().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFC: nci: uart: Set tty->disc_data only in success pathSetting tty->disc_data before opening the NCI device means we need toclean it up on error paths. This also opens some short window if devicestarts sending data, even before NCIUARTSETDRIVER IOCTL succeeded(broken hardware?). Close the window by exposing tty->disc_data only onthe success path, when opening of the NCI device and try_module_get()succeeds.The code differs in error path in one aspect: tty->disc_data won't beever assigned thus NULL-ified. This however should not be relevantdifference, because of "tty->disc_data=NULL" in nci_uart_tty_open().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Fix use-after-free in tipc_conn_close().syzbot reported a null-ptr-deref in tipc_conn_close() during netnsdismantle. [0]tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and callstipc_conn_close() for each tipc_conn.The problem is that tipc_conn_close() is called after releasing theIDR lock.At the same time, there might be tipc_conn_recv_work() running and itcould call tipc_conn_close() for the same tipc_conn and release itslast ->kref.Once we release the IDR lock in tipc_topsrv_stop(), there is noguarantee that the tipc_conn is alive.Let's hold the ref before releasing the lock and put the ref aftertipc_conn_close() in tipc_topsrv_stop().[0]:BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: netns cleanup_netCall Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fc/0x2ef lib/dump_stack.c:118 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasan_report mm/kasan/report.c:412 [inline] __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline] tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415Allocated by task 23: kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415Freed by task 23: __cache_free mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline] kref_put include/linux/kref.h:70 [inline] conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00)The buggy address belongs to the page:page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0flags: 0xfff00000000100(slab)raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc>ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:padata: Fix pd UAF once and for allThere is a race condition/UAF in padata_reorder that goes backto the initial commit. A reference count is taken at the startof the process in padata_do_parallel, and released at the end inpadata_serial_worker.This reference count is (and only is) required for padata_replaceto function correctly. If padata_replace is never called thenthere is no issue.In the function padata_reorder which serves as the core of padata,as soon as padata is added to queue->serial.list, and the associatedspin lock released, that padata may be processed and the referencecount on pd would go away.Fix this by getting the next padata before the squeue->serial lockis released.In order to make this possible, simplify padata_reorder by onlycalling it once the next padata arrives.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocatedIn case of an ib_fast_reg_mr allocation failure during iSER setup, themachine hits a panic because iscsi_conn->dd_data is initializedunconditionally, even when no memory is allocated (dd_size == 0). Thisleads invalid pointer dereference during connection teardown.Fix by setting iscsi_conn->dd_data only if memory is actually allocated.Panic trace:------------ iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swake_up_locked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0 [ib_iser] iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi] iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi] iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi] ? netlink_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_from_user+0x29/0x60 sock_sendmsg+0x5f/0x70
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_reject: don't leak dst refcount for loopback packetsrecent patches to add a WARN() when replacing skb dst entry found anold bug:WARNING: include/linux/skbuff.h:1165 skb_dst_check_unset include/linux/skbuff.h:1164 [inline]WARNING: include/linux/skbuff.h:1165 skb_dst_set include/linux/skbuff.h:1210 [inline]WARNING: include/linux/skbuff.h:1165 nf_reject_fill_skb_dst+0x2a4/0x330 net/ipv4/netfilter/nf_reject_ipv4.c:234[..]Call Trace: nf_send_unreach+0x17b/0x6e0 net/ipv4/netfilter/nf_reject_ipv4.c:325 nft_reject_inet_eval+0x4bc/0x690 net/netfilter/nft_reject_inet.c:27 expr_call_ops_eval net/netfilter/nf_tables_core.c:237 [inline] ..This is because blamed commit forgot about loopback packets.Such packets already have a dst_entry attached, even at PRE_ROUTING stage.Instead of checking hook just check if the skb already has a routeattached to it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: prevent NULL pointer dereference in UTF16 conversionThere can be a NULL pointer dereference bug here. NULL is passed to__cifs_sfu_make_node without checks, which passes it unchecked tocifs_strndup_to_utf16, which in turn passes it tocifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash.This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 andreturns NULL early to prevent dereferencing NULL pointer.Found by Linux Verification Center (linuxtesting.org) with SVACE
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd/pgtbl: Fix possible race while increase page table levelThe AMD IOMMU host page table implementation supports dynamic page table levels(up to 6 levels), starting with a 3-level configuration that expands based onIOVA address. The kernel maintains a root pointer and current page table levelto enable proper page table walks in alloc_pte()/fetch_pte() operations.The IOMMU IOVA allocator initially starts with 32-bit address and onces itsexhuasted it switches to 64-bit address (max address is determined basedon IOMMU and device DMA capability). To support larger IOVA, AMD IOMMUdriver increases page table level.But in unmap path (iommu_v1_unmap_pages()), fetch_pte() readspgtable->[root/mode] without lock. So its possible that in exteme corner case,when increase_address_space() is updating pgtable->[root/mode], fetch_pte()reads wrong page table level (pgtable->mode). It does compare the value withlevel encoded in page table and returns NULL. This will result isiommu_unmap ops to fail and upper layer may retry/log WARN_ON.CPU 0 CPU 1------ ------map pages unmap pagesalloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1)Since Page table level updates are infrequent and already synchronized with aspinlock, implement seqcount to enable lock-free read operations on the read path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mvsas: Fix use-after-free bugs in mvs_work_queueDuring the detaching of Marvell's SAS/SATA controller, the original codecalls cancel_delayed_work() in mvs_free() to cancel the delayed workitem mwq->work_q. However, if mwq->work_q is already running, thecancel_delayed_work() may fail to cancel it. This can lead touse-after-free scenarios where mvs_free() frees the mvs_info whilemvs_work_queue() is still executing and attempts to access thealready-freed mvs_info.A typical race condition is illustrated below:CPU 0 (remove) | CPU 1 (delayed work callback)mvs_pci_remove() | mvs_free() | mvs_work_queue() cancel_delayed_work() | kfree(mvi) | | mvi-> // UAFReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the delayed work item is properly canceled and any executingdelayed work item completes before the mvs_info is deallocated.This bug was found by static analysis.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: cadence-quadspi: Implement refcount to handle unbind during busydriver support indirect read and indirect write operation withassumption no force device removal(unbind) operation. Howeverforce device removal(removal) is still available to root superuser.Unbinding driver during operation causes kernel crash. This changesensure driver able to handle such operation for indirect read andindirect write by implementing refcount to track attached devicesto the controller and gracefully wait and until attached devicesremove operation completed before proceed with removal operation.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/sched: Fix potential double free in drm_sched_job_add_resv_dependenciesWhen adding dependencies with drm_sched_job_add_dependency(), thatfunction consumes the fence reference both on success and failure, so inthe latter case the dma_fence_put() on the error path (xarray failed toexpand) is a double free.Interestingly this bug appears to have been present ever sincecommit ebd5f74255b9 ("drm/sched: Add dependency tracking"), since the codeback then looked like this:drm_sched_job_add_implicit_dependencies():... for (i = 0; i < fence_count; i++) { ret = drm_sched_job_add_dependency(job, fences[i]); if (ret) break; } for (; i < fence_count; i++) dma_fence_put(fences[i]);Which means for the failing 'i' the dma_fence_put was already a doublefree. Possibly there were no users at that time, or the test cases wereinsufficient to hit it.The bug was then only noticed and fixed aftercommit 9c2ba265352a ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2")landed, with its fixup ofcommit 4eaf02d6076c ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies").At that point it was a slightly different flavour of a double free, whichcommit 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder")noticed and attempted to fix.But it only moved the double free from happening inside thedrm_sched_job_add_dependency(), when releasing the reference not yetobtained, to the caller, when releasing the reference already released bythe former in the failure case.As such it is not easy to identify the right target for the fixes tag solets keep it simple and just continue the chain.While fixing we also improve the comment and explain the reason for takingthe reference and not dropping it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdumpDo not block PCI config accesses through pci_cfg_access_lock() whenexecuting the s390 variant of PCI error recovery: Acquire justdevice_lock() instead of pci_dev_lock() as powerpc's EEH andgenerig PCI AER processing do.During error recovery testing a pair of tasks was reported to be hung:mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not workingINFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168 [<0000000652513212>] devlink_health_report+0x19a/0x230 [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]No kernel log of the exact same error with an upstream kernel isavailable - but the very same deadlock situation can be constructed there,too:- task: kmcheck mlx5_unload_one() tries to acquire devlink lock while the PCI error recovery code has set pdev->block_cfg_access by way of pci_cfg_access_lock()- task: kworker mlx5_crdump_collect() tries to set block_cfg_access through pci_cfg_access_lock() while devlink_health_report() had acquired the devlink lock.A similar deadlock situation can be reproduced by requesting acrdump with > devlink health dump show pci/ reporter fw_fatalwhile PCI error recovery is executed on the same physical functionby mlx5_core's pci_error_handlers. On s390 this can be injected with > zpcictl --reset-fw Tests with this patch failed to reproduce that second deadlock situation,the devlink command is rejected with "kernel answers: Permission denied" -and we get a kernel log message of:mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5because the config read of VSC_SEMAPHORE is rejected by the underlyinghardware.Two prior attempts to address this issue have been discussed andultimately rejected [see link], with the primary argument that s390'simplementation of PCI error recovery is imposing restrictions thatneither powerpc's EEH nor PCI AER handling need. Tests show that PCIerror recovery on s390 is running to completion even without blockingaccess to PCI config space.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: Avoid overflowing userspace buffer on stats queryThe ethtool -S command operates across three ioctl calls:ETHTOOL_GSSET_INFO for the size, ETHTOOL_GSTRINGS for the names, andETHTOOL_GSTATS for the values.If the number of stats changes between these calls (e.g., due to devicereconfiguration), userspace's buffer allocation will be incorrect,potentially leading to buffer overflow.Drivers are generally expected to maintain stable stat counts, but somedrivers (e.g., mlx5, bnx2x, bna, ksz884x) use dynamic counters, makingthis scenario possible.Some drivers try to handle this internally:- bnad_get_ethtool_stats() returns early in case stats.n_stats is not equal to the driver's stats count.- micrel/ksz884x also makes sure not to write anything beyond stats.n_stats and overflow the buffer.However, both use stats.n_stats which is already assigned with the valuereturned from get_sset_count(), hence won't solve the issue describedhere.Change ethtool_get_strings(), ethtool_get_stats(),ethtool_get_phy_stats() to not return anything in case of a mismatchbetween userspace's size and get_sset_size(), to prevent bufferoverflow.The returned n_stats value will be equal to zero, to reflect thatnothing has been returned.This could result in one of two cases when using upstream ethtool,depending on when the size change is detected:1. When detected in ethtool_get_strings(): # ethtool -S eth2 no stats available2. When detected in get stats, all stats will be reported as zero.Both cases are presumably transient, and a subsequent ethtool callshould succeed.Other than the overflow avoidance, these two cases are very evident (nooutput/cleared stats), which is arguably better than presentingincorrect/shifted stats.I also considered returning an error instead of a "silent" response, butthat seems more destructive towards userspace apps.Notes:- This patch does not claim to fix the inherent race, it only makes sure that we do not overflow the userspace buffer, and makes for a more predictable behavior.- RTNL lock is held during each ioctl, the race window exists between the separate ioctl calls when the lock is released.- Userspace ethtool always fills stats.n_stats, but it is likely that these stats ioctls are implemented in other userspace applications which might not fill it. The added code checks that it's not zero, to prevent any regressions.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:efivarfs: fix error propagation in efivar_entry_get()efivar_entry_get() always returns success even if the underlying__efivar_entry_get() fails, masking errors.This may result in uninitialized heap memory being copied to userspacein the efivarfs_file_read() path.Fix it by returning the error from __efivar_entry_get().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: split cached_fid bitfields to avoid shared-byte RMW racesis_open, has_lease and on_list are stored in the same bitfield byte instruct cached_fid but are updated in different code paths that may runconcurrently. Bitfield assignments generate byte read-modify-writeoperations (e.g. `orb $mask, addr` on x86_64), so updating one flag canrestore stale values of the others.A possible interleaving is: CPU1: load old byte (has_lease=1, on_list=1) CPU2: clear both flags (store 0) CPU1: RMW store (old | IS_OPEN) -> reintroduces cleared bitsTo avoid this class of races, convert these flags to separate boolfields.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sync: annotate data-races around hdev->req_status__hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock: hdev->req_status = HCI_REQ_PEND;However, several other functions read or write hdev->req_status withoutholding any lock: - hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue) - hci_cmd_sync_complete() reads/writes from HCI event completion - hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write - hci_abort_conn() reads in connection abort pathSince __hci_cmd_sync_sk() runs on hdev->req_workqueue whilehci_send_cmd_sync() runs on hdev->workqueue, these are differentworkqueues that can execute concurrently on different CPUs. The plainC accesses constitute a data race.Add READ_ONCE()/WRITE_ONCE() annotations on all concurrent accessesto hdev->req_status to prevent potential compiler optimizations thatcould affect correctness (e.g., load fusing in the wait_eventcondition or store reordering).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ntb: ntb_hw_switchtec: Fix shift-out-of-bounds for 0 mw lutNumber of MW LUTs depends on NTB configuration and can be set to zero,in such scenario rounddown_pow_of_two will cause undefined behaviour andshould not be performed.This patch ensures that rounddown_pow_of_two is called on valid value.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:minix: Add required sanity checking to minix_check_superblock()The fs/minix implementation of the minix filesystem does not currentlysupport any other value for s_log_zone_size than 0. This is also theonly value supported in util-linux; see mkfs.minix.c line 511. Inaddition, this patch adds some sanity checking for the other minixsuperblock fields, and moves the minix_blocks_needed() checks for thezmap and imap also to minix_check_super_block().This also closes a related syzbot bug report.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Fix WRITE_SAME No Data Buffer crashIn newer version of the SBC specs, we have a NDOB bit that indicates thereis no data buffer that gets written out. If this bit is set using commandslike "sg_write_same --ndob" we will crash in target_core_iblock/file'sexecute_write_same handlers when we go to access the se_cmd->t_data_sgbecause its NULL.This patch adds a check for the NDOB bit in the common WRITE SAME codebecause we don't support it. And, it adds a check for zero SG elements ineach handler in case the initiator tries to send a normal WRITE SAME withno data buffer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Fix not checking skb length on hci_acldata_packetThis fixes not checking if skb really contains an ACL header otherwisethe code may attempt to access some uninitilized/invalid memory past thevalid skb->data.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:landlock: Fix handling of disconnected directoriesDisconnected files or directories can appear when they are visible andopened from a bind mount, but have been renamed or moved from the sourceof the bind mount in a way that makes them inaccessible from the mountpoint (i.e. out of scope).Previously, access rights tied to files or directories opened through adisconnected directory were collected by walking the related hierarchydown to the root of the filesystem, without taking into account themount point because it couldn't be found. This could lead toinconsistent access results, potential access right widening, andhard-to-debug renames, especially since such paths cannot be printed.For a sandboxed task to create a disconnected directory, it needs tohave write access (i.e. FS_MAKE_REG, FS_REMOVE_FILE, and FS_REFER) tothe underlying source of the bind mount, and read access to the relatedmount point. Because a sandboxed task cannot acquire more accessrights than those defined by its Landlock domain, this could lead toinconsistent access rights due to missing permissions that should beinherited from the mount point hierarchy, while inheriting permissionsfrom the filesystem hierarchy hidden by this mount point instead.Landlock now handles files and directories opened from disconnecteddirectories by taking into account the filesystem hierarchy when themount point is not found in the hierarchy walk, and also always takinginto account the mount point from which these disconnected directorieswere opened. This ensures that a rename is not allowed if it wouldwiden access rights [1].The rationale is that, even if disconnected hierarchies might not bevisible or accessible to a sandboxed task, relying on the collectedaccess rights from them improves the guarantee that access rights willnot be widened during a rename because of the access right comparisonbetween the source and the destination (see LANDLOCK_ACCESS_FS_REFER).It may look like this would grant more access on disconnected files anddirectories, but the security policies are always enforced for all theevaluated hierarchies. This new behavior should be less surprising tousers and safer from an access control perspective.Remove a wrong WARN_ON_ONCE() canary in collect_domain_accesses() andfix the related comment.Because opened files have their access rights stored in the related filesecurity properties, there is no impact for disconnected or unlinkedfiles.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix middle attribute validation in push_nsh() actionThe push_nsh() action structure looks like this: OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...))The outermost OVS_ACTION_ATTR_PUSH_NSH attribute is OK'ed by thenla_for_each_nested() inside __ovs_nla_copy_actions(). The innermostOVS_NSH_KEY_ATTR_BASE/MD1/MD2 are OK'ed by the nla_for_each_nested()inside nsh_key_put_from_nlattr(). But nothing checks if the attributein the middle is OK. We don't even check that this attribute is theOVS_KEY_ATTR_NSH. We just do a double unwrap with a pair of nla_data()calls - first time directly while calling validate_push_nsh() and thesecond time as part of the nla_for_each_nested() macro, which isn'tsafe, potentially causing invalid memory access if the size of thisattribute is incorrect. The failure may not be noticed duringvalidation due to larger netlink buffer, but cause trouble later duringaction execution where the buffer is allocated exactly to the size: BUG: KASAN: slab-out-of-bounds in nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] Read of size 184 at addr ffff88816459a634 by task a.out/22624 CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary) Call Trace: dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x2c/0x390 kasan_report+0xdd/0x110 kasan_check_range+0x35/0x1b0 __asan_memcpy+0x20/0x60 nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] push_nsh+0x82/0x120 [openvswitch] do_execute_actions+0x1405/0x2840 [openvswitch] ovs_execute_actions+0xd5/0x3b0 [openvswitch] ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch] genl_family_rcv_msg_doit+0x1d6/0x2b0 genl_family_rcv_msg+0x336/0x580 genl_rcv_msg+0x9f/0x130 netlink_rcv_skb+0x11f/0x370 genl_rcv+0x24/0x40 netlink_unicast+0x73e/0xaa0 netlink_sendmsg+0x744/0xbf0 __sys_sendto+0x3d6/0x450 do_syscall_64+0x79/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Let's add some checks that the attribute is properly sized and it'sthe only one attribute inside the action. Technically, there is noreal reason for OVS_KEY_ATTR_NSH to be there, as we know that we'repushing an NSH header already, it just creates extra nesting, butthat's how uAPI works today. So, keeping as it is.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- glibc > 0-0 (version in image is 2.31-150300.98.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: avoid possible UaF when selecting endpselect_local_address() and select_signal_address() both select anendpoint entry from the list inside an RCU protected section, but returna reference to it, to be read later on. If the entry is dereferencedafter the RCU unlock, reading info could cause a Use-after-Free.A simple solution is to copy the required info while inside the RCUprotected section to avoid any risk of UaF later. The address ID mightneed to be modified later to handle the ID0 case later, so a copy seemsOK to deal with.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libxml2-2 > 0-0 (version in image is 2.10.3-150500.5.38.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: lan743x: Modify the EEPROM and OTP size for PCI1xxxx devicesMaximum OTP and EEPROM size for hearthstone PCI1xxxx devices are 8 Kband 64 Kb respectively. Adjust max size definitions and return correctEEPROM length based on device. Also prevent out-of-bound read/write.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: Vim is an open source, command line text editor. In versions from 9.1.1231 to before 9.1.1406, when processing nested tuples during Vim9 script import operations, an error during evaluation can trigger a double-free in Vim's internal typed value (typval_T) management. Specifically, the clear_tv() function may attempt to free memory that has already been deallocated, due to improper lifetime handling in the handle_import / ex_import code paths. The vulnerability can only be triggered if a user explicitly opens and executes a specially crafted Vim script. This issue has been patched in version 9.1.1406.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- vim > 0-0 (version in image is 9.2.0280-150500.20.46.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iavf: fix off-by-one issues in iavf_config_rss_reg()There are off-by-one bugs when configuring RSS hash key and lookuptable, causing out-of-bounds reads to memory [1] and out-of-boundswrites to device registers.Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"),the loop upper bounds were: i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEXwhich is safe since the value is the last valid index.That commit changed the bounds to: i <= adapter->rss_{key,lut}_size / 4where `rss_{key,lut}_size / 4` is the number of dwords, so the lastvalid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `<=`accesses one element past the end.Fix the issues by using `<` instead of `<=`, ensuring we do not exceedthe bounds.[1] KASAN splat about rss_key_size off-by-one BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800 Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63 CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: iavf iavf_watchdog_task Call Trace: dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x1a0 iavf_config_rss+0x619/0x800 iavf_watchdog_task+0x2be7/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 Allocated by task 63: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x246/0x6f0 iavf_watchdog_task+0x28fc/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 The buggy address belongs to the object at ffff888102c50100 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes to the right of allocated 52-byte region [ffff888102c50100, ffff888102c50134) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50 flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix race in mptcp_pm_nl_flush_addrs_doit()syzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id()and/or mptcp_pm_nl_is_backup()Root cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit()which is not RCU ready.list_splice_init_rcu() can not be called here while holding pernet->lockspinlock.Many thanks to Eulgyu Kim for providing a repro and testing our patches.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix stack-out-of-bounds write in devmapget_upper_ifindexes() iterates over all upper devices and writes theirindices into an array without checking bounds.Also the callers assume that the max number of upper devices isMAX_NEST_DEV and allocate excluded_devices[1+MAX_NEST_DEV] on the stack,but that assumption is not correct and the number of upper devices couldbe larger than MAX_NEST_DEV (e.g., many macvlans), causing astack-out-of-bounds write.Add a max parameter to get_upper_ifindexes() to avoid the issue.When there are too many upper devices, return -EOVERFLOW and abort theredirect.To reproduce, create more than MAX_NEST_DEV(8) macvlans on a device withan XDP program attached using BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS.Then send a packet to the device to trigger the XDP redirect path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libblkid1 > 0-0 (version in image is 2.37.4-150500.9.26.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: reject direct access to nullable PTR_TO_BUF pointerscheck_mem_access() matches PTR_TO_BUF via base_type() which stripsPTR_MAYBE_NULL, allowing direct dereference without a null check.Map iterator ctx->key and ctx->value are PTR_TO_BUF | PTR_MAYBE_NULL.On stop callbacks these are NULL, causing a kernel NULL dereference.Add a type_may_be_null() guard to the PTR_TO_BUF branch, matching theexisting PTR_TO_BTF_ID pattern.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Fix a use-after-freeThere are two .exit_cmd_priv implementations. Both implementations useresources associated with the SCSI host. Make sure that these resources arestill available when .exit_cmd_priv is called by waiting insidescsi_remove_host() until the tag set has been freed.This commit fixes the following use-after-free:==================================================================BUG: KASAN: use-after-free in srp_exit_cmd_priv+0x27/0xd0 [ib_srp]Read of size 8 at addr ffff888100337000 by task multipathd/16727Call Trace: dump_stack_lvl+0x34/0x44 print_report.cold+0x5e/0x5db kasan_report+0xab/0x120 srp_exit_cmd_priv+0x27/0xd0 [ib_srp] scsi_mq_exit_request+0x4d/0x70 blk_mq_free_rqs+0x143/0x410 __blk_mq_free_map_and_rqs+0x6e/0x100 blk_mq_free_tag_set+0x2b/0x160 scsi_host_dev_release+0xf3/0x1a0 device_release+0x54/0xe0 kobject_put+0xa5/0x120 device_release+0x54/0xe0 kobject_put+0xa5/0x120 scsi_device_dev_release_usercontext+0x4c1/0x4e0 execute_in_process_context+0x23/0x90 device_release+0x54/0xe0 kobject_put+0xa5/0x120 scsi_disk_release+0x3f/0x50 device_release+0x54/0xe0 kobject_put+0xa5/0x120 disk_release+0x17f/0x1b0 device_release+0x54/0xe0 kobject_put+0xa5/0x120 dm_put_table_device+0xa3/0x160 [dm_mod] dm_put_device+0xd0/0x140 [dm_mod] free_priority_group+0xd8/0x110 [dm_multipath] free_multipath+0x94/0xe0 [dm_multipath] dm_table_destroy+0xa2/0x1e0 [dm_mod] __dm_destroy+0x196/0x350 [dm_mod] dev_remove+0x10c/0x160 [dm_mod] ctl_ioctl+0x2c2/0x590 [dm_mod] dm_ctl_ioctl+0x5/0x10 [dm_mod] __x64_sys_ioctl+0xb4/0xf0 dm_ctl_ioctl+0x5/0x10 [dm_mod] __x64_sys_ioctl+0xb4/0xf0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix information leakage in /proc/net/ptypeIn one net namespace, after creating a packet socket without bindingit to a device, users in other net namespaces can observe the new`packet_type` added by this packet socket by reading `/proc/net/ptype`file. This is minor information leakage as packet socket isnamespace aware.Add a net pointer in `packet_type` to keep the net namespace ofof corresponding packet socket. In `ptype_seq_show`, this net pointermust be checked when it is not NULL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not WARN_ON() if we have PageError setWhenever we do any extent buffer operations we callassert_eb_page_uptodate() to complain loudly if we're operating on annon-uptodate page. Our overnight tests caught this warning earlier thisweek WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50 CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G W 5.17.0-rc3+ #564 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Workqueue: btrfs-cache btrfs_work_helper RIP: 0010:assert_eb_page_uptodate+0x3f/0x50 RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246 RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000 RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000 R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1 R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0 Call Trace: extent_buffer_test_bit+0x3f/0x70 free_space_test_bit+0xa6/0xc0 load_free_space_tree+0x1f6/0x470 caching_thread+0x454/0x630 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? lock_release+0x1f0/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_release+0x1f0/0x2d0 ? finish_task_switch.isra.0+0xf9/0x3a0 process_one_work+0x26d/0x580 ? process_one_work+0x580/0x580 worker_thread+0x55/0x3b0 ? process_one_work+0x580/0x580 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30This was partially fixed by c2e39305299f01 ("btrfs: clear extent bufferuptodate when we fail to write it"), however all that fix did was keepus from finding extent buffers after a failed writeout. It didn't keepus from continuing to use a buffer that we already had found.In this case we're searching the commit root to cache the block group,so we can start committing the transaction and switch the commit rootand then start writing. After the switch we can look up an extentbuffer that hasn't been written yet and start processing that blockgroup. Then we fail to write that block out and clear Uptodate on thepage, and then we start spewing these errors.Normally we're protected by the tree lock to a certain degree here. Ifwe read a block we have that block read locked, and we block the writerfrom locking the block before we submit it for the write. However thisisn't necessarily fool proof because the read could happen before we dothe submit_bio and after we locked and unlocked the extent buffer.Also in this particular case we have path->skip_locking set, so thatwon't save us here. We'll simply get a block that was valid when weread it, but became invalid while we were using it.What we really want is to catch the case where we've "read" a block butit's not marked Uptodate. On read we ClearPageError(), so if we're!Uptodate and !Error we know we didn't do the right thing for readingthe page.Fix this by checking !Uptodate && !Error, this way we will not complainif our buffer gets invalidated while we're using it, and we'll maintainthe spirit of the check which is to make sure we have a fully in-cacheblock while we're messing with it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:riscv: fix oops caused by irqsoff latency tracerThe trace_hardirqs_{on,off}() require the caller to setup frame pointerproperly. This because these two functions use macro 'CALLER_ADDR1' (aka.__builtin_return_address(1)) to acquire caller info. If the $fp is usedfor other purpose, the code generated this macro (as below) could triggermemory access fault. 0xffffffff8011510e <+80>: ld a1,-16(s0) 0xffffffff80115112 <+84>: ld s2,-8(a1) # <-- paging fault hereThe oops message during booting if compiled with 'irqoff' tracer enabled:[ 0.039615][ T0] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8[ 0.041925][ T0] Oops [#1][ 0.042063][ T0] Modules linked in:[ 0.042864][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-rc1-00233-g9a20c48d1ed2 #29[ 0.043568][ T0] Hardware name: riscv-virtio,qemu (DT)[ 0.044343][ T0] epc : trace_hardirqs_on+0x56/0xe2[ 0.044601][ T0] ra : restore_all+0x12/0x6e[ 0.044721][ T0] epc : ffffffff80126a5c ra : ffffffff80003b94 sp : ffffffff81403db0[ 0.044801][ T0] gp : ffffffff8163acd8 tp : ffffffff81414880 t0 : 0000000000000020[ 0.044882][ T0] t1 : 0098968000000000 t2 : 0000000000000000 s0 : ffffffff81403de0[ 0.044967][ T0] s1 : 0000000000000000 a0 : 0000000000000001 a1 : 0000000000000100[ 0.045046][ T0] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000[ 0.045124][ T0] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000054494d45[ 0.045210][ T0] s2 : ffffffff80003b94 s3 : ffffffff81a8f1b0 s4 : ffffffff80e27b50[ 0.045289][ T0] s5 : ffffffff81414880 s6 : ffffffff8160fa00 s7 : 00000000800120e8[ 0.045389][ T0] s8 : 0000000080013100 s9 : 000000000000007f s10: 0000000000000000[ 0.045474][ T0] s11: 0000000000000000 t3 : 7fffffffffffffff t4 : 0000000000000000[ 0.045548][ T0] t5 : 0000000000000000 t6 : ffffffff814aa368[ 0.045620][ T0] status: 0000000200000100 badaddr: 00000000000000f8 cause: 000000000000000d[ 0.046402][ T0] [] restore_all+0x12/0x6eThis because the $fp(aka. $s0) register is not used as frame pointer in theassembly entry code. resume_kernel: REG_L s0, TASK_TI_PREEMPT_COUNT(tp) bnez s0, restore_all REG_L s0, TASK_TI_FLAGS(tp) andi s0, s0, _TIF_NEED_RESCHED beqz s0, restore_all call preempt_schedule_irq j restore_allTo fix above issue, here we add one extra level wrapper for functiontrace_hardirqs_{on,off}() so they can be safely called by low level entrycode.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix memory leak during stateful obj updatestateful objects can be updated from the control plane.The transaction logic allocates a temporary object for this purpose.The ->init function was called for this object, so plain kfree() leaksresources. We must call ->destroy function of the object.nft_obj_destroy does this, but it also decrements the module refcount,but the update path doesn't increment it.To avoid special-casing the update object release, do module_get forthe update case too and release it via nft_obj_destroy().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: mt7621: Add sentinel to quirks tableCurrent driver is missing a sentinel in the struct soc_device_attributearray, which causes an oops when assessed by thesoc_device_match(mt7621_pcie_quirks_match) call.This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attrwas fixed to register the SOC as a device, in:commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early")Fix it by adding the required sentinel.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: fix memory leak in sctp_stream_outq_migrate()When sctp_stream_outq_migrate() is called to release stream out resources,the memory pointed to by prio_head in stream out is not released.The memory leak information is as follows: unreferenced object 0xffff88801fe79f80 (size 64): comm "sctp_repo", pid 7957, jiffies 4294951704 (age 36.480s) hex dump (first 32 bytes): 80 9f e7 1f 80 88 ff ff 80 9f e7 1f 80 88 ff ff ................ 90 9f e7 1f 80 88 ff ff 90 9f e7 1f 80 88 ff ff ................ backtrace: [] kmalloc_trace+0x26/0x60 [] sctp_sched_prio_set+0x4cc/0x770 [] sctp_stream_init_ext+0xd2/0x1b0 [] sctp_sendmsg_to_asoc+0x1614/0x1a30 [] sctp_sendmsg+0xda1/0x1ef0 [] inet_sendmsg+0x9d/0xe0 [] sock_sendmsg+0xd3/0x120 [] __sys_sendto+0x23a/0x340 [] __x64_sys_sendto+0xe1/0x1b0 [] do_syscall_64+0x39/0xb0 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libbpf: Handle size overflow for ringbuf mmapThe maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entrieswill overflow u32 when mapping producer page and data pages. Onlycasting max_entries to size_t is not enough, because for 32-bitsapplication on 64-bits kernel the size of read-only mmap regionalso could overflow size_t.So fixing it by casting the size of read-only mmap region into a __u64and checking whether or not there will be overflow during mmap.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit()Syzkaller reported BUG as follows: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 Call Trace: dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item inbtrfs_run_qgroups() later outside of the spinlock context.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: dev: check return value when calling dev_set_name()If dev_set_name() fails, the dev_name() is null, check the returnvalue of dev_set_name() to avoid the null-ptr-deref.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/secretmem: fix panic when growing a memfd_secretWhen one tries to grow an existing memfd_secret with ftruncate, one getsa panic [1]. For example, doing the following reliably induces thepanic: fd = memfd_secret(); ftruncate(fd, 10); ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); strcpy(ptr, "123456789"); munmap(ptr, 10); ftruncate(fd, 20);The basic reason for this is, when we grow with ftruncate, we call downinto simple_setattr, and then truncate_inode_pages_range, and eventuallywe try to zero part of the memory. The normal truncation code does thisvia the direct map (i.e., it calls page_address() and hands that tomemset()).For memfd_secret though, we specifically don't map our pages via thedirect map (i.e. we call set_direct_map_invalid_noflush() on everyfault). So the address returned by page_address() isn't useful, andwhen we try to memset() with it we panic.This patch avoids the panic by implementing a custom setattr formemfd_secret, which detects resizes specifically (setting the size forthe first time works just fine, since there are no existing pages to tryto zero), and rejects them with EINVAL.One could argue growing should be supported, but I think that willrequire a significantly more lengthy change. So, I propose a minimalfix for the benefit of stable kernels, and then perhaps to extendmemfd_secret to support growing in a separate patch.[1]: BUG: unable to handle page fault for address: ffffa0a889277028 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD afa01067 P4D afa01067 PUD 83f909067 PMD 83f8bf067 PTE 800ffffef6d88060 Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI CPU: 0 PID: 281 Comm: repro Not tainted 5.17.0-dbg-DEV #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:memset_erms+0x9/0x10 Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01 RSP: 0018:ffffb932c09afbf0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffda63c4249dc0 RCX: 0000000000000fd8 RDX: 0000000000000fd8 RSI: 0000000000000000 RDI: ffffa0a889277028 RBP: ffffb932c09afc00 R08: 0000000000001000 R09: ffffa0a889277028 R10: 0000000000020023 R11: 0000000000000000 R12: ffffda63c4249dc0 R13: ffffa0a890d70d98 R14: 0000000000000028 R15: 0000000000000fd8 FS: 00007f7294899580(0000) GS:ffffa0af9bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa0a889277028 CR3: 0000000107ef6006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? zero_user_segments+0x82/0x190 truncate_inode_partial_folio+0xd4/0x2a0 truncate_inode_pages_range+0x380/0x830 truncate_setsize+0x63/0x80 simple_setattr+0x37/0x60 notify_change+0x3d8/0x4d0 do_sys_ftruncate+0x162/0x1d0 __x64_sys_ftruncate+0x1c/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: xhci_pci xhci_hcd virtio_net net_failover failover virtio_blk virtio_balloon uhci_hcd ohci_pci ohci_hcd evdev ehci_pci ehci_hcd 9pnet_virtio 9p netfs 9pnet CR2: ffffa0a889277028[lkp@intel.com: secretmem_iops can be static][axelrasmussen@google.com: return EINVAL]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: fix a race in rxrpc_exit_net()Current code can lead to the following race:CPU0 CPU1rxrpc_exit_net() rxrpc_peer_keepalive_worker() if (rxnet->live) rxnet->live = false; del_timer_sync(&rxnet->peer_keepalive_timer); timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay); cancel_work_sync(&rxnet->peer_keepalive_work);rxrpc_exit_net() exits while peer_keepalive_timer is still armed,leading to use-after-free.syzbot report was:ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505Modules linked in:CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: netns cleanup_netRIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: __debug_check_no_obj_freed lib/debugobjects.c:992 [inline] debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023 kfree+0xd6/0x310 mm/slab.c:3809 ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176 ops_free_list net/core/net_namespace.c:174 [inline] cleanup_net+0x591/0xb00 net/core/net_namespace.c:598 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/tls: fix slab-out-of-bounds bug in decrypt_internalThe memory size of tls_ctx->rx.iv for AES128-CCM is 12 setting intls_set_sw_offload(). The return value of crypto_aead_ivsize()for "ccm(aes)" is 16. So memcpy() require 16 bytes from 12 bytesmemory space will trigger slab-out-of-bounds bug as following:==================================================================BUG: KASAN: slab-out-of-bounds in decrypt_internal+0x385/0xc40 [tls]Read of size 16 at addr ffff888114e84e60 by task tls/10911Call Trace: dump_stack_lvl+0x34/0x44 print_report.cold+0x5e/0x5db ? decrypt_internal+0x385/0xc40 [tls] kasan_report+0xab/0x120 ? decrypt_internal+0x385/0xc40 [tls] kasan_check_range+0xf9/0x1e0 memcpy+0x20/0x60 decrypt_internal+0x385/0xc40 [tls] ? tls_get_rec+0x2e0/0x2e0 [tls] ? process_rx_list+0x1a5/0x420 [tls] ? tls_setup_from_iter.constprop.0+0x2e0/0x2e0 [tls] decrypt_skb_update+0x9d/0x400 [tls] tls_sw_recvmsg+0x3c8/0xb50 [tls]Allocated by task 10911: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 tls_set_sw_offload+0x2eb/0xa20 [tls] tls_setsockopt+0x68c/0x700 [tls] __sys_setsockopt+0xfe/0x1b0Replace the crypto_aead_ivsize() with prot->iv_size + prot->salt_sizewhen memcpy() iv value in TLS_1_3_VERSION scenario.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ref_tracker: implement use-after-free detectionWhenever ref_tracker_dir_init() is called, mark the struct ref_tracker_diras dead.Test the dead status from ref_tracker_alloc() and ref_tracker_free()This should detect buggy dev_put()/dev_hold() happening too latein netdevice dismantle process.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: felix: fix possible NULL pointer dereferenceAs the possible failure of the allocation, kzalloc() may return NULLpointer.Therefore, it should be better to check the 'sgi' in order to preventthe dereference of NULL pointer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: mediatek: Fix error handling in mt8183_da7219_max98357_dev_probeThe device_node pointer is returned by of_parse_phandle() with refcountincremented. We should use of_node_put() on it when done.This function only calls of_node_put() in the regular path.And it will cause refcount leak in error paths.Fix this by calling of_node_put() in error handling too.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not double complete bio on errors during compressed readsI hit some weird panics while fixing up the error handling frombtrfs_lookup_bio_sums(). Turns out the compression path will completethe bio we use if we set up any of the compression bios and then returnan error, and then btrfs_submit_data_bio() will also call bio_endio() onthe bio.Fix this by making btrfs_submit_compressed_read() responsible forcalling bio_endio() on the bio if there are any errors. Currently itwas only doing it if we created the compression bios, otherwise it wasdepending on btrfs_submit_data_bio() to do the right thing. Thiscreates the above problem, so fix up btrfs_submit_compressed_read() toalways call bio_endio() in case of an error, and then simply return frombtrfs_submit_data_bio() if we had to callbtrfs_submit_compressed_read().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not clean up repair bio if submit failsThe submit helper will always run bio_endio() on the bio if it fails tosubmit, so cleaning up the bio just leads to a variety of use-after-freeand NULL pointer dereference bugs because we race with the endiofunction that is cleaning up the bio. Instead just return BLK_STS_OK asthe repair function has to continue to process the rest of the pages,and the endio for the repair bio will do the appropriate cleanup for thepage that it was given.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl/port: Hold port reference until decoder releaseKASAN + DEBUG_KOBJECT_RELEASE reports a potential use-after-free incxl_decoder_release() where it goes to reference its parent, a cxl_port,to free its id back to port->decoder_ida. BUG: KASAN: use-after-free in to_cxl_port+0x18/0x90 [cxl_core] Read of size 8 at addr ffff888119270908 by task kworker/35:2/379 CPU: 35 PID: 379 Comm: kworker/35:2 Tainted: G OE 5.17.0-rc2+ #198 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events kobject_delayed_cleanup Call Trace: dump_stack_lvl+0x59/0x73 print_address_description.constprop.0+0x1f/0x150 ? to_cxl_port+0x18/0x90 [cxl_core] kasan_report.cold+0x83/0xdf ? to_cxl_port+0x18/0x90 [cxl_core] to_cxl_port+0x18/0x90 [cxl_core] cxl_decoder_release+0x2a/0x60 [cxl_core] device_release+0x5f/0x100 kobject_cleanup+0x80/0x1c0The device core only guarantees parent lifetime until all children areunregistered. If a child needs a parent to complete its ->release()callback that child needs to hold a reference to extend the lifetime ofthe parent.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: unregister virtual clocks when unregistering physical clock.When unregistering a physical clock which has some virtual clocks,unregister the virtual clocks with it.This fixes the following oops, which can be triggered by unloadinga driver providing a PTP clock when it has enabled virtual clocks:BUG: unable to handle page fault for address: ffffffffc04fc4d8Oops: 0000 [#1] PREEMPT SMP NOPTIRIP: 0010:ptp_vclock_read+0x31/0xb0Call Trace: timecounter_read+0xf/0x50 ptp_vclock_refresh+0x2c/0x50 ? ptp_clock_release+0x40/0x40 ptp_aux_kworker+0x17/0x30 kthread_worker_fn+0x9b/0x240 ? kthread_should_park+0x30/0x30 kthread+0xe2/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: Avoid cross-chip syncing of VLAN filteringChanges to VLAN filtering are not applicable to cross-chipnotifications.On a system like this:.-----. .-----. .-----.| sw1 +---+ sw2 +---+ sw3 |'-1-2-' '-1-2-' '-1-2-'Before this change, upon sw1p1 leaving a bridge, a call todsa_port_vlan_filtering would also be made to sw2p1 and sw3p1.In this scenario:.---------. .-----. .-----.| sw1 +---+ sw2 +---+ sw3 |'-1-2-3-4-' '-1-2-' '-1-2-'When sw1p4 would leave a bridge, dsa_port_vlan_filtering would becalled for sw2 and sw3 with a non-existing port - leading to arrayout-of-bounds accesses and crashes on mv88e6xxx.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip_gre: test csum_start instead of transport headerGRE with TUNNEL_CSUM will apply local checksum offload onCHECKSUM_PARTIAL packets.ipgre_xmit must validate csum_start after an optional skb_pull,else lco_csum may trigger an overflow. The original check was if (csum && skb_checksum_start(skb) < skb->data) return -EINVAL;This had false positives when skb_checksum_start is undefined:when ip_summed is not CHECKSUM_PARTIAL. A discussed refinementwas straightforward if (csum && skb->ip_summed == CHECKSUM_PARTIAL && skb_checksum_start(skb) < skb->data) return -EINVAL;But was eventually revised more thoroughly:- restrict the check to the only branch where needed, in an uncommon GRE path that uses header_ops and calls skb_pull.- test skb_transport_header, which is set along with csum_start in skb_partial_csum_set in the normal header_ops datapath.Turns out skbs can arrive in this branch without the transportheader set, e.g., through BPF redirection.Revise the check back to check csum_start directly, and only ifCHECKSUM_PARTIAL. Do leave the check in the updated location.Check field regardless of whether TUNNEL_CSUM is configured.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: memleak flow rule from commit pathAbort path release flow rule object, however, commit path does not.Update code to destroy these objects before releasing the transaction.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: annotate races around sk->sk_bound_dev_ifUDP sendmsg() is lockless, and reads sk->sk_bound_dev_if whilethis field can be changed by another thread.Adds minimal annotations to avoid KCSAN splats for UDP.Following patches will add more annotations to potential lockless readers.BUG: KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsgwrite to 0xffff888136d47a94 of 4 bytes by task 7681 on cpu 0: __ip6_datagram_connect+0x6e2/0x930 net/ipv6/datagram.c:221 ip6_datagram_connect+0x2a/0x40 net/ipv6/datagram.c:272 inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576 __sys_connect_file net/socket.c:1900 [inline] __sys_connect+0x197/0x1b0 net/socket.c:1917 __do_sys_connect net/socket.c:1927 [inline] __se_sys_connect net/socket.c:1924 [inline] __x64_sys_connect+0x3d/0x50 net/socket.c:1924 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeread to 0xffff888136d47a94 of 4 bytes by task 7670 on cpu 1: udpv6_sendmsg+0xc60/0x16e0 net/ipv6/udp.c:1436 inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:652 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2413 ___sys_sendmsg net/socket.c:2467 [inline] __sys_sendmmsg+0x267/0x4c0 net/socket.c:2553 __do_sys_sendmmsg net/socket.c:2582 [inline] __se_sys_sendmmsg net/socket.c:2579 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2579 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaevalue changed: 0x00000000 -> 0xffffff9bReported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 7670 Comm: syz-executor.3 Tainted: G W 5.18.0-rc1-syzkaller-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011I chose to not add Fixes: tag because race has minor consequencesand stable teams busy enough.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix anon_dev leak in create_subvol()When btrfs_qgroup_inherit(), btrfs_alloc_tree_block, orbtrfs_insert_root() fail in create_subvol(), we return without freeinganon_dev. Reorganize the error handling in create_subvol() to fix this.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rtw89: cfo: check mac_id to avoid out-of-boundsSomehow, hardware reports incorrect mac_id and pollute memory. Check indexbefore we access the array. UBSAN: array-index-out-of-bounds in rtw89/phy.c:2517:23 index 188 is out of range for type 's32 [64]' CPU: 1 PID: 51550 Comm: irq/35-rtw89_pc Tainted: G OE Call Trace: show_stack+0x52/0x58 dump_stack_lvl+0x4c/0x63 dump_stack+0x10/0x12 ubsan_epilogue+0x9/0x45 __ubsan_handle_out_of_bounds.cold+0x44/0x49 ? __alloc_skb+0x92/0x1d0 rtw89_phy_cfo_parse+0x44/0x7f [rtw89_core] rtw89_core_rx+0x261/0x871 [rtw89_core] ? __alloc_skb+0xee/0x1d0 rtw89_pci_napi_poll+0x3fa/0x4ea [rtw89_pci] __napi_poll+0x33/0x1a0 net_rx_action+0x126/0x260 ? __queue_work+0x217/0x4c0 __do_softirq+0xd9/0x315 ? disable_irq_nosync+0x10/0x10 do_softirq.part.0+0x6d/0x90 __local_bh_enable_ip+0x62/0x70 rtw89_pci_interrupt_threadfn+0x182/0x1a6 [rtw89_pci] irq_thread_fn+0x28/0x60 irq_thread+0xc8/0x190 ? irq_thread_fn+0x60/0x60 kthread+0x16b/0x190 ? irq_thread_check_affinity+0xe0/0xe0 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: prevent kernel crash when rmmod mtk-vcodec-dec.koIf the driver support subdev mode, the parameter "dev->pm.dev" will beNULL in mtk_vcodec_dec_remove. Kernel will crash when try to rmmodmtk-vcodec-dec.ko.[ 4380.702726] pc : do_raw_spin_trylock+0x4/0x80[ 4380.707075] lr : _raw_spin_lock_irq+0x90/0x14c[ 4380.711509] sp : ffff80000819bc10[ 4380.714811] x29: ffff80000819bc10 x28: ffff3600c03e4000 x27: 0000000000000000[ 4380.721934] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000[ 4380.729057] x23: ffff3600c0f34930 x22: ffffd5e923549000 x21: 0000000000000220[ 4380.736179] x20: 0000000000000208 x19: ffffd5e9213e8ebc x18: 0000000000000020[ 4380.743298] x17: 0000002000000000 x16: ffffd5e9213e8e90 x15: 696c346f65646976[ 4380.750420] x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000040[ 4380.757542] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000[ 4380.764664] x8 : 0000000000000000 x7 : ffff3600c7273ae8 x6 : ffffd5e9213e8ebc[ 4380.771786] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000[ 4380.778908] x2 : 0000000000000000 x1 : ffff3600c03e4000 x0 : 0000000000000208[ 4380.786031] Call trace:[ 4380.788465] do_raw_spin_trylock+0x4/0x80[ 4380.792462] __pm_runtime_disable+0x2c/0x1b0[ 4380.796723] mtk_vcodec_dec_remove+0x5c/0xa0 [mtk_vcodec_dec][ 4380.802466] platform_remove+0x2c/0x60[ 4380.806204] __device_release_driver+0x194/0x250[ 4380.810810] driver_detach+0xc8/0x15c[ 4380.814462] bus_remove_driver+0x5c/0xb0[ 4380.818375] driver_unregister+0x34/0x64[ 4380.822288] platform_driver_unregister+0x18/0x24[ 4380.826979] mtk_vcodec_dec_driver_exit+0x1c/0x888 [mtk_vcodec_dec][ 4380.833240] __arm64_sys_delete_module+0x190/0x224[ 4380.838020] invoke_syscall+0x48/0x114[ 4380.841760] el0_svc_common.constprop.0+0x60/0x11c[ 4380.846540] do_el0_svc+0x28/0x90[ 4380.849844] el0_svc+0x4c/0x100[ 4380.852975] el0t_64_sync_handler+0xec/0xf0[ 4380.857148] el0t_64_sync+0x190/0x194[ 4380.860801] Code: 94431515 17ffffca d503201f d503245f (b9400004)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: dw9714: Disable the regulator when the driver fails to probeWhen the driver fails to probe, we will get the following splat:[ 59.305988] ------------[ cut here ]------------[ 59.306417] WARNING: CPU: 2 PID: 395 at drivers/regulator/core.c:2257 _regulator_put+0x3ec/0x4e0[ 59.310345] RIP: 0010:_regulator_put+0x3ec/0x4e0[ 59.318362] Call Trace:[ 59.318582] [ 59.318765] regulator_put+0x1f/0x30[ 59.319058] devres_release_group+0x319/0x3d0[ 59.319420] i2c_device_probe+0x766/0x940Fix this by disabling the regulator in error handling.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: avoid skb access on nf_stolenWhen verdict is NF_STOLEN, the skb might have been freed.When tracing is enabled, this can result in a use-after-free:1. access to skb->nf_trace2. access to skb->mark3. computation of trace id4. dump of packet payloadTo avoid 1, keep a cached copy of skb->nf_trace in thetrace state struct.Refresh this copy whenever verdict is != STOLEN.Avoid 2 by skipping skb->mark access if verdict is STOLEN.3 is avoided by precomputing the trace id.Only dump the packet when verdict is not "STOLEN".
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nexthop: Fix data-races around nexthop_compat_mode.While reading nexthop_compat_mode, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:icmp: Fix data-races around sysctl_icmp_echo_enable_probe.While reading sysctl_icmp_echo_enable_probe, it can be changedconcurrently. Thus, we need to add READ_ONCE() to its readers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: Fix a data-race around sysctl_fib_sync_mem.While reading sysctl_fib_sync_mem, it can be changed concurrently.So, we need to add READ_ONCE() to avoid a data-race.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ovl: Use "buf" flexible array for memcpy() destinationThe "buf" flexible array needs to be the memcpy() destination to avoidfalse positive run-time warning from the recent FORTIFY_SOURCEhardening: memcpy: detected field-spanning write (size 93) of single field "&fh->fb" at fs/overlayfs/export.c:799 (size 21)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: designware: use casting of u64 in clock multiplication to avoid overflowIn functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflowby depending on the values of the given parameters including the ic_clk.For example in our use case where ic_clk is larger than one million,multiplication of ic_clk * 4700 will result in 32 bit overflow.Add cast of u64 to the calculation to avoid multiplication overflow, anduse the corresponding define for divide.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/highbank: Fix memory leak in highbank_mc_probe()When devres_open_group() fails, it returns -ENOMEM without freeing memoryallocated by edac_mc_alloc().Call edac_mc_free() on the error handling path to avoid a memory leak. [ bp: Massage commit message. ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:reset: uniphier-glue: Fix possible null-ptr-derefIt will cause null-ptr-deref when resource_size(res) invoked,if platform_get_resource() returns NULL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: always report error in run_one_delayed_ref()Currently we have a btrfs_debug() for run_one_delayed_ref() failure, butif end users hit such problem, there will be no chance thatbtrfs_debug() is enabled. This can lead to very little useful info fordebugging.This patch will:- Add extra info for error reporting Including: * logical bytenr * num_bytes * type * action * ref_mod- Replace the btrfs_debug() with btrfs_err()- Move the error reporting into run_one_delayed_ref() This is to avoid use-after-free, the @node can be freed in the caller.This error should only be triggered at most once.As if run_one_delayed_ref() failed, we trigger the error message, thencausing the call chain to error out:btrfs_run_delayed_refs()`- btrfs_run_delayed_refs() `- btrfs_run_delayed_refs_for_head() `- run_one_delayed_ref()And we will abort the current transaction in btrfs_run_delayed_refs().If we have to run delayed refs for the abort transaction,run_one_delayed_ref() will just cleanup the refs and do nothing, thus nonew error messages would be output.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Prevent bpf program recursion for raw tracepoint probesWe got report from sysbot [1] about warnings that were caused bybpf program attached to contention_begin raw tracepoint triggeringthe same tracepoint by using bpf_trace_printk helper that takestrace_printk_lock lock. Call Trace: ? trace_event_raw_event_bpf_trace_printk+0x5f/0x90 bpf_trace_printk+0x2b/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 __unfreeze_partials+0x5b/0x160 ...The can be reproduced by attaching bpf program as raw tracepoint oncontention_begin tracepoint. The bpf prog calls bpf_trace_printkhelper. Then by running perf bench the spin lock code is forced totake slow path and call contention_begin tracepoint.Fixing this by skipping execution of the bpf program if it'salready running, Using bpf prog 'active' field, which is beingcurrently used by trampoline programs for the same reason.Moving bpf_prog_inc_misses_counter to syscall.c becausetrampoline.c is compiled in just for CONFIG_BPF_JIT option.[1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: use a dedicated spinlock for trans_fdShamelessly copying the explanation from Tetsuo Handa's suggestedpatch[1] (slightly reworded):syzbot is reporting inconsistent lock state in p9_req_put()[2],for p9_tag_remove() from p9_req_put() from IRQ context is usingspin_lock_irqsave() on "struct p9_client"->lock but trans_fd(not from IRQ context) is using spin_lock().Since the locks actually protect different things in client.c and intrans_fd.c, just replace trans_fd.c's lock by a new one specific to thetransport (client.c's protect the idr for fid/tag allocations,while trans_fd.c's protects its own req list and request status fieldthat acts as the transport's state machine)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:9p: trans_fd/p9_conn_cancel: drop client lock earliersyzbot reported a double-lock here and we no longer need thislock after requests have been moved off to local list:just drop the lock earlier.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/sgx: Add overflow check in sgx_validate_offset_length()sgx_validate_offset_length() function verifies "offset" and "length"arguments provided by userspace, but was missing an overflow check ontheir addition. Add it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: Fix memory leak of nsim_dev->fa_cookiekmemleak reports this issue:unreferenced object 0xffff8881bac872d0 (size 8): comm "sh", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] __kmalloc+0x49/0x150 [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [<0000000093d78e77>] full_proxy_write+0xf3/0x180 [<000000005a662c16>] vfs_write+0x1c5/0xaf0 [<000000007aabf84a>] ksys_write+0xed/0x1c0 [<000000005f1d2e47>] do_syscall_64+0x3b/0x90 [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcdThe issue occurs in the following scenarios:nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev->fa_cookie = fa_cookie..nsim_drv_remove()The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. Tofix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: microchip: sparx5: Fix potential null-ptr-deref in sparx_stats_init() and sparx5_start()sparx_stats_init() calls create_singlethread_workqueue() and notchecked the ret value, which may return NULL. And a null-ptr-deref mayhappen:sparx_stats_init() create_singlethread_workqueue() # failed, sparx5->stats_queue is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-derefCheck the ret value and return -ENOMEM if it is NULL. So assparx5_start().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: don't leak tagger-owned storage on switch driver unbindIn the initial commit dc452a471dba ("net: dsa: introduce tagger-ownedstorage for private and shared data"), we had a call totag_ops->disconnect(dst) issued from dsa_tree_free(), which is called attree teardown time.There were problems with connecting to a switch tree as a whole, so thisgot reworked to connecting to individual switches within the tree. Inthis process, tag_ops->disconnect(ds) was made to be called only fromswitch.c (cross-chip notifiers emitted as a result of dynamic tag protochanges), but the normal driver teardown code path wasn't replaced withanything.Solve this problem by adding a function that does the opposite ofdsa_switch_setup_tag_protocol(), which is called from the equivalentspot in dsa_switch_teardown(). The positioning here also ensures that wewon't have any use-after-free in tagging protocol (*rcv) ops, since theteardown sequence is as follows:dsa_tree_teardown-> dsa_tree_teardown_master -> dsa_master_teardown -> unsets master->dsa_ptr, making no further packets match the ETH_P_XDSA packet type handler-> dsa_tree_teardown_ports -> dsa_port_teardown -> dsa_slave_destroy -> unregisters DSA net devices, there is even a synchronize_net() in unregister_netdevice_many()-> dsa_tree_teardown_switches -> dsa_switch_teardown -> dsa_switch_teardown_tag_protocol -> finally frees the tagger-owned storage
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hugetlbfs: don't delete error page from pagecacheThis change is very similar to the change that was made for shmem [1], andit solves the same problem but for HugeTLBFS instead.Currently, when poison is found in a HugeTLB page, the page is removedfrom the page cache. That means that attempting to map or read thathugepage in the future will result in a new hugepage being allocatedinstead of notifying the user that the page was poisoned. As [1] states,this is effectively memory corruption.The fix is to leave the page in the page cache. If the user attempts touse a poisoned HugeTLB page with a syscall, the syscall will fail withEIO, the same error code that shmem uses. For attempts to map the page,the thread will get a BUS_MCEERR_AR SIGBUS.[1]: commit a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: initialize device's zone info for seedingWhen performing seeding on a zoned filesystem it is necessary toinitialize each zoned device's btrfs_zoned_device_info structure,otherwise mounting the filesystem will cause a NULL pointer dereference.This was uncovered by fstests' testcase btrfs/163.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: clone zoned device info when cloning a deviceWhen cloning a btrfs_device, we're not cloning the associatedbtrfs_zoned_device_info structure of the device in case of a zonedfilesystem.Later on this leads to a NULL pointer dereference when accessing thedevice's zone_info for instance when setting a zone as active.This was uncovered by fstests' testcase btrfs/161.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb()We got a syzkaller problem because of aarch64 alignment faultif KFENCE enabled. When the size from user bpf program is an oddnumber, like 399, 407, etc, it will cause the struct skb_shared_info'sunaligned access. As seen below: BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 Use-after-free read at 0xffff6254fffac077 (in kfence-#213): __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline] arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline] arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline] atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline] __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 skb_clone+0xf4/0x214 net/core/skbuff.c:1481 ____bpf_clone_redirect net/core/filter.c:2433 [inline] bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420 bpf_prog_d3839dd9068ceb51+0x80/0x330 bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline] bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53 bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512 allocated by task 15074 on cpu 0 at 1342.585390s: kmalloc include/linux/slab.h:568 [inline] kzalloc include/linux/slab.h:675 [inline] bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191 bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381To fix the problem, we adjust @size so that (@size + @hearoom) is amultiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_infois aligned to a cache line.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: gso: fix panic on frag_list with mixed head alloc typesSince commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat whensplitting gso_size mangled skb having linear-headed frag_list"), it isallowed to change gso_size of a GRO packet. However, that commit assumesthat "checking the first list_skb member suffices; i.e if either of thelist_skb members have non head_frag head, then the first one has too".It turns out this assumption does not hold. We've seen BUG_ON being hitin skb_segment when skbs on the frag_list had differing head_frag withthe vmxnet3 driver. This happens because __netdev_alloc_skb and__napi_alloc_skb can return a skb that is page backed or kmalloceddepending on the requested size. As the result, the last small skb inthe GRO packet can be kmalloced.There are three different locations where this can be fixed:(1) We could check head_frag in GRO and not allow GROing skbs with different head_frag. However, that would lead to performance regression on normal forward paths with unmodified gso_size, where !head_frag in the last packet is not a problem.(2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating that NETIF_F_SG is undesirable. That would need to eat a bit in sk_buff. Furthermore, that flag can be unset when all skbs on the frag_list are page backed. To retain good performance, bpf_skb_net_grow/shrink would have to walk the frag_list.(3) Walk the frag_list in skb_segment when determining whether NETIF_F_SG should be cleared. This of course slows things down.This patch implements (3). To limit the performance impact inskb_segment, the list is walked only for skbs with SKB_GSO_DODGY setthat have gso_size changed. Normal paths thus will not hit it.We could check only the last skb but since we need to walk the wholelist anyway, let's stay on the safe side.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queuesWhen running `test_sockmap` selftests, the following warning appears: WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0 Call Trace: inet_csk_destroy_sock+0x55/0x110 tcp_rcv_state_process+0xd28/0x1380 ? tcp_v4_do_rcv+0x77/0x2c0 tcp_v4_do_rcv+0x77/0x2c0 __release_sock+0x106/0x130 __tcp_close+0x1a7/0x4e0 tcp_close+0x20/0x70 inet_release+0x3c/0x80 __sock_release+0x3a/0xb0 sock_close+0x14/0x20 __fput+0xa3/0x260 task_work_run+0x59/0xb0 exit_to_user_mode_prepare+0x1b3/0x1c0 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x48/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xaeThe root case is in commit 84472b436e76 ("bpf, sockmap: Fix more unchargedwhile msg has more_data"), where I used msg->sg.size to replace the tosend,causing breakage: if (msg->apply_bytes && msg->apply_bytes < tosend) tosend = psock->apply_bytes;
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix WARNING in ip6_route_net_exit_late()During the initialization of ip6_route_net_init_late(), if fileipv6_route or rt6_stats fails to be created, the initialization issuccessful by default. Therefore, the ipv6_route or rt6_stats filedoesn't be found during the remove in ip6_route_net_exit_late(). Itwill cause WRNING.The following is the stack information:name 'rt6_stats'WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460Modules linked in:Workqueue: netns cleanup_netRIP: 0010:remove_proc_entry+0x389/0x460PKRU: 55555554Call Trace:ops_exit_list+0xb0/0x170cleanup_net+0x4ea/0xb00process_one_work+0x9bf/0x1710worker_thread+0x665/0x1080kthread+0x2e4/0x3a0ret_from_fork+0x1f/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Don't redirect packets with invalid pkt_lenSyzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout anyskbs, that is, the flow->head is null.The root cause, as the [2] says, is because that bpf_prog_test_run_skb()run a bpf prog which redirects empty skbs.So we should determine whether the length of the packet modified by bpfprog or others like bpf_prog_test is valid before forwarding it directly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix warning in ext4_iomap_begin as race between bmap and writeWe got issue as follows:------------[ cut here ]------------WARNING: CPU: 3 PID: 9310 at fs/ext4/inode.c:3441 ext4_iomap_begin+0x182/0x5d0RIP: 0010:ext4_iomap_begin+0x182/0x5d0RSP: 0018:ffff88812460fa08 EFLAGS: 00010293RAX: ffff88811f168000 RBX: 0000000000000000 RCX: ffffffff97793c12RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003RBP: ffff88812c669160 R08: ffff88811f168000 R09: ffffed10258cd20fR10: ffff88812c669077 R11: ffffed10258cd20e R12: 0000000000000001R13: 00000000000000a4 R14: 000000000000000c R15: ffff88812c6691eeFS: 00007fd0d6ff3740(0000) GS:ffff8883af180000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fd0d6dda290 CR3: 0000000104a62000 CR4: 00000000000006e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: iomap_apply+0x119/0x570 iomap_bmap+0x124/0x150 ext4_bmap+0x14f/0x250 bmap+0x55/0x80 do_vfs_ioctl+0x952/0xbd0 __x64_sys_ioctl+0xc6/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9Above issue may happen as follows: bmap writebmap ext4_bmap iomap_bmap ext4_iomap_begin ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin ext4_prepare_inline_data ext4_create_inline_data ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); if (WARN_ON_ONCE(ext4_has_inline_data(inode))) ->trigger bug_onTo solved above issue hold inode lock in ext4_bamp.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix memory leak when using fscacheIf we hit the 'index == next_cached' case, we leak a refcount on thestruct page. Fix this by using readahead_folio() which takes care ofthe refcount for you.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: fbtft: core: set smem_len before fb_deferred_io_init callThe fbtft_framebuffer_alloc() calls fb_deferred_io_init() beforeinitializing info->fix.smem_len. It is set to zero by theframebuffer_alloc() function. It will trigger a WARN_ON() at thestart of fb_deferred_io_init() and the function will not do anything.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:of: check previous kernel's ima-kexec-buffer against memory boundsPresently ima_get_kexec_buffer() doesn't check if the previous kernel'sima-kexec-buffer lies outside the addressable memory range. This can resultin a kernel panic if the new kernel is booted with 'mem=X' arg and theima-kexec-buffer was allocated beyond that range by the previous kernel.The panic is usually of the form below:$ sudo kexec --initrd initrd vmlinux --append='mem=16G'
BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000 Faulting instruction address: 0xc000000000837974 Oops: Kernel access of bad area, sig: 11 [#1] NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0 LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 Call Trace: [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108 [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120 [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0 [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0 [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330 7c0802a6 fb610198 7c9b2378 f80101d0 2c090001 40820614 e9240010 ---[ end trace 0000000000000000 ]---Fix this issue by checking returned PFN range of previous kernel'sima-kexec-buffer with page_is_ram() to ensure correct memory bounds.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, x86: fix freeing of not-finalized bpf_prog_packsyzbot reported a few issues with bpf_prog_pack [1], [2]. This only happenswith multiple subprogs. In jit_subprogs(), we first call bpf_int_jit_compile()on each sub program. And then, we call it on each sub program again. jit_datais not freed in the first call of bpf_int_jit_compile(). Similarly we don'tcall bpf_jit_binary_pack_finalize() in the first call of bpf_int_jit_compile().If bpf_int_jit_compile() failed for one sub program, we will callbpf_jit_binary_pack_finalize() for this sub program. However, we don't have achance to call it for other sub programs. Then we will hit "goto out_free" injit_subprogs(), and call bpf_jit_free on some subprograms that haven't gotbpf_jit_binary_pack_finalize() yet.At this point, bpf_jit_binary_pack_free() is called and the whole 2MB page isfreed erroneously.Fix this with a custom bpf_jit_free() for x86_64, which callsbpf_jit_binary_pack_finalize() if necessary. Also, with custombpf_jit_free(), bpf_prog_aux->use_bpf_prog_pack is not needed any more,remove it.[1] https://syzkaller.appspot.com/bug?extid=2f649ec6d2eea1495a8f[2] https://syzkaller.appspot.com/bug?extid=87f65c75f4a72db05445
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86/mmu: Treat NX as a valid SPTE bit for NPTTreat the NX bit as valid when using NPT, as KVM will set the NX bit whenthe NX huge page mitigation is enabled (mindblowing) and trigger the WARNthat fires on reserved SPTE bits being set.KVM has required NX support for SVM since commit b26a71a1a5b9 ("KVM: SVM:Refuse to load kvm_amd if NX support is not available") for exactly thisreason, but apparently it never occurred to anyone to actually test NPTwith the mitigation enabled. ------------[ cut here ]------------ spte = 0x800000018a600ee7, level = 2, rsvd bits = 0x800f0000001fe000 WARNING: CPU: 152 PID: 15966 at arch/x86/kvm/mmu/spte.c:215 make_spte+0x327/0x340 [kvm] Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 10.48.0 01/27/2022 RIP: 0010:make_spte+0x327/0x340 [kvm] Call Trace: tdp_mmu_map_handle_target_level+0xc3/0x230 [kvm] kvm_tdp_mmu_map+0x343/0x3b0 [kvm] direct_page_fault+0x1ae/0x2a0 [kvm] kvm_tdp_page_fault+0x7d/0x90 [kvm] kvm_mmu_page_fault+0xfb/0x2e0 [kvm] npf_interception+0x55/0x90 [kvm_amd] svm_invoke_exit_handler+0x31/0xf0 [kvm_amd] svm_handle_exit+0xf6/0x1d0 [kvm_amd] vcpu_enter_guest+0xb6d/0xee0 [kvm] ? kvm_pmu_trigger_event+0x6d/0x230 [kvm] vcpu_run+0x65/0x2c0 [kvm] kvm_arch_vcpu_ioctl_run+0x355/0x610 [kvm] kvm_vcpu_ioctl+0x551/0x610 [kvm] __se_sys_ioctl+0x77/0xc0 __x64_sys_ioctl+0x1d/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/mediatek: Fix crash on isr after kexec()If the system is rebooted via isr(), the IRQ handler mightbe triggered before the domain is initialized. Resulting onan invalid memory access error.Fix:[ 0.500930] Unable to handle kernel read from unreadable memory at virtual address 0000000000000070[ 0.501166] Call trace:[ 0.501174] report_iommu_fault+0x28/0xfc[ 0.501180] mtk_iommu_isr+0x10c/0x1c0[ joro: Fixed spelling in commit message ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: handle the error returned from sctp_auth_asoc_init_active_keyWhen it returns an error from sctp_auth_asoc_init_active_key(), theactive_key is actually not updated. The old sh_key will be freeedwhile it's still used as active key in asoc. Then an use-after-freewill be triggered when sending patckets, as found by syzbot: sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112 sctp_set_owner_w net/sctp/socket.c:132 [inline] sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863 sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025 inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734This patch is to fix it by not replacing the sh_key when it returnserrors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key().For sctp_auth_set_active_key(), old active_key_id will be set backto asoc->active_key_id when the same thing happens.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl: fix possible null-ptr-deref in cxl_pci_init_afu|adapter()If device_register() fails in cxl_pci_afu|adapter(), the deviceis not added, device_unregister() can not be called in the errorpath, otherwise it will cause a null-ptr-deref because of removingnot added device.As comment of device_register() says, it should use put_device() to giveup the reference in the error path. So split device_unregister() intodevice_del() and put_device(), then goes to put dev when register fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: make sure skb->len != 0 when redirecting to a tunneling devicesyzkaller managed to trigger another case where skb->len == 0when we enter __dev_queue_xmit:WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline]WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 __dev_queue_xmit+0x2069/0x35e0 net/core/dev.c:4295Call Trace: dev_queue_xmit+0x17/0x20 net/core/dev.c:4406 __bpf_tx_skb net/core/filter.c:2115 [inline] __bpf_redirect_no_mac net/core/filter.c:2140 [inline] __bpf_redirect+0x5fb/0xda0 net/core/filter.c:2163 ____bpf_clone_redirect net/core/filter.c:2447 [inline] bpf_clone_redirect+0x247/0x390 net/core/filter.c:2419 bpf_prog_48159a89cb4a9a16+0x59/0x5e bpf_dispatcher_nop_func include/linux/bpf.h:897 [inline] __bpf_prog_run include/linux/filter.h:596 [inline] bpf_prog_run include/linux/filter.h:603 [inline] bpf_test_run+0x46c/0x890 net/bpf/test_run.c:402 bpf_prog_test_run_skb+0xbdc/0x14c0 net/bpf/test_run.c:1170 bpf_prog_test_run+0x345/0x3c0 kernel/bpf/syscall.c:3648 __sys_bpf+0x43a/0x6c0 kernel/bpf/syscall.c:5005 __do_sys_bpf kernel/bpf/syscall.c:5091 [inline] __se_sys_bpf kernel/bpf/syscall.c:5089 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5089 do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x61/0xc6The reproducer doesn't really reproduce outside of syzkallerenvironment, so I'm taking a guess here. It looks like wedo generate correct ETH_HLEN-sized packet, but we redirectthe packet to the tunneling device. Before we do so, we__skb_pull l2 header and arrive again at skb->len == 0.Doesn't seem like we can do anything better than havingan explicit check after __skb_pull?
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: fix race in sock_map_free()sock_map_free() calls release_sock(sk) without owning a referenceon the socket. This can cause use-after-free as syzbot found [1]Jakub Sitnicki already took care of a similar issuein sock_hash_free() in commit 75e68e5bf2c7 ("bpf, sockhash:Synchronize delete from bucket list on map free")[1]refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 0 PID: 3785 at lib/refcount.c:31 refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31Modules linked in:CPU: 0 PID: 3785 Comm: kworker/u4:6 Not tainted 6.1.0-rc7-syzkaller-00103-gef4d3ea40565 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022Workqueue: events_unbound bpf_map_free_deferredRIP: 0010:refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31Code: 68 8b 31 c0 e8 75 71 15 fd 0f 0b e9 64 ff ff ff e8 d9 6e 4e fd c6 05 62 9c 3d 0a 01 48 c7 c7 80 bb 68 8b 31 c0 e8 54 71 15 fd <0f> 0b e9 43 ff ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a2 fe ffRSP: 0018:ffffc9000456fb60 EFLAGS: 00010246RAX: eae59bab72dcd700 RBX: 0000000000000004 RCX: ffff8880207057c0RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000RBP: 0000000000000004 R08: ffffffff816fdabd R09: fffff520008adee5R10: fffff520008adee5 R11: 1ffff920008adee4 R12: 0000000000000004R13: dffffc0000000000 R14: ffff88807b1c6c00 R15: 1ffff1100f638dcfFS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b30c30000 CR3: 000000000d08e000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:__refcount_dec include/linux/refcount.h:344 [inline]refcount_dec include/linux/refcount.h:359 [inline]__sock_put include/net/sock.h:779 [inline]tcp_release_cb+0x2d0/0x360 net/ipv4/tcp_output.c:1092release_sock+0xaf/0x1c0 net/core/sock.c:3468sock_map_free+0x219/0x2c0 net/core/sock_map.c:356process_one_work+0x81c/0xd10 kernel/workqueue.c:2289worker_thread+0xb14/0x1330 kernel/workqueue.c:2436kthread+0x266/0x300 kernel/kthread.c:376ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: annotate data-races around kcm->rx_waitkcm->rx_psock can be read locklessly in kcm_rfree().Annotate the read and writes accordingly.syzbot reported:BUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfreewrite to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1:reserve_rx_kcm net/kcm/kcmsock.c:283 [inline]kcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301strp_recv+0x6d/0x80 net/strparser/strparser.c:335tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703strp_read_sock net/strparser/strparser.c:358 [inline]do_strp_work net/strparser/strparser.c:406 [inline]strp_work+0xe8/0x180 net/strparser/strparser.c:415process_one_work+0x3d3/0x720 kernel/workqueue.c:2289worker_thread+0x618/0xa70 kernel/workqueue.c:2436kthread+0x1a9/0x1e0 kernel/kthread.c:376ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0:kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841skb_release_all net/core/skbuff.c:852 [inline]__kfree_skb net/core/skbuff.c:868 [inline]kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891kfree_skb include/linux/skbuff.h:1216 [inline]kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161____sys_recvmsg+0x16c/0x2e0___sys_recvmsg net/socket.c:2743 [inline]do_recvmmsg+0x2f1/0x710 net/socket.c:2837__sys_recvmmsg net/socket.c:2916 [inline]__do_sys_recvmmsg net/socket.c:2939 [inline]__se_sys_recvmmsg net/socket.c:2932 [inline]__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x01 -> 0x00Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to do sanity check on destination blkaddr during recoveryAs Wenqing Liu reported in bugzilla:https://bugzilla.kernel.org/show_bug.cgi?id=216456loop5: detected capacity change from 0 to 131072F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0F2FS-fs (loop5): Bitmap was wrongly set, blk:5634------------[ cut here ]------------WARNING: CPU: 3 PID: 1013 at fs/f2fs/segment.c:2198RIP: 0010:update_sit_entry+0xa55/0x10b0 [f2fs]Call Trace: f2fs_do_replace_block+0xa98/0x1890 [f2fs] f2fs_replace_block+0xeb/0x180 [f2fs] recover_data+0x1a69/0x6ae0 [f2fs] f2fs_recover_fsync_data+0x120d/0x1fc0 [f2fs] f2fs_fill_super+0x4665/0x61e0 [f2fs] mount_bdev+0x2cf/0x3b0 legacy_get_tree+0xed/0x1d0 vfs_get_tree+0x81/0x2b0 path_mount+0x47e/0x19d0 do_mount+0xce/0xf0 __x64_sys_mount+0x12c/0x1a0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcdIf we enable CONFIG_F2FS_CHECK_FS config, it will trigger a kernel panicinstead of warning.The root cause is: in fuzzed image, SIT table is inconsistent with inodemapping table, result in triggering such warning during SIT table update.This patch introduces a new flag DATA_GENERIC_ENHANCE_UPDATE, w/ thisflag, data block recovery flow can check destination blkaddr's validationin SIT table, and skip f2fs_replace_block() to avoid inconsistent status.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: annotate data-races around kcm->rx_psockkcm->rx_psock can be read locklessly in kcm_rfree().Annotate the read and writes accordingly.We do the same for kcm->rx_wait in the following patch.syzbot reported:BUG: KCSAN: data-race in kcm_rfree / unreserve_rx_kcmwrite to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1:unreserve_rx_kcm+0x72/0x1f0 net/kcm/kcmsock.c:313kcm_rcv_strparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301strp_recv+0x6d/0x80 net/strparser/strparser.c:335tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703strp_read_sock net/strparser/strparser.c:358 [inline]do_strp_work net/strparser/strparser.c:406 [inline]strp_work+0xe8/0x180 net/strparser/strparser.c:415process_one_work+0x3d3/0x720 kernel/workqueue.c:2289worker_thread+0x618/0xa70 kernel/workqueue.c:2436kthread+0x1a9/0x1e0 kernel/kthread.c:376ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306read to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0:kcm_rfree+0x14c/0x220 net/kcm/kcmsock.c:181skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841skb_release_all net/core/skbuff.c:852 [inline]__kfree_skb net/core/skbuff.c:868 [inline]kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891kfree_skb include/linux/skbuff.h:1216 [inline]kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161____sys_recvmsg+0x16c/0x2e0___sys_recvmsg net/socket.c:2743 [inline]do_recvmmsg+0x2f1/0x710 net/socket.c:2837__sys_recvmmsg net/socket.c:2916 [inline]__do_sys_recvmmsg net/socket.c:2939 [inline]__se_sys_recvmmsg net/socket.c:2932 [inline]__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0xffff88812971ce00 -> 0x0000000000000000Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not BUG_ON() on ENOMEM when dropping extent items for a rangeIf we get -ENOMEM while dropping file extent items in a given range, atbtrfs_drop_extents(), due to failure to allocate memory when attempting toincrement the reference count for an extent or drop the reference count,we handle it with a BUG_ON(). This is excessive, instead we can simplyabort the transaction and return the error to the caller. In fact mostcallers of btrfs_drop_extents(), directly or indirectly, already abortthe transaction if btrfs_drop_extents() returns any error.Also, we already have error paths at btrfs_drop_extents() that may return-ENOMEM and in those cases we abort the transaction, like for exampleanything that changes the b+tree may return -ENOMEM due to a failure toallocate a new extent buffer when COWing an existing extent buffer, suchas a call to btrfs_duplicate_item() for example.So replace the BUG_ON() calls with proper logic to abort the transactionand return the error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: core: fix possible resource leak in init_mtd()I got the error report while inject fault in init_mtd():sysfs: cannot create duplicate filename '/devices/virtual/bdi/mtd-0'Call Trace: dump_stack_lvl+0x67/0x83 sysfs_warn_dup+0x60/0x70 sysfs_create_dir_ns+0x109/0x120 kobject_add_internal+0xce/0x2f0 kobject_add+0x98/0x110 device_add+0x179/0xc00 device_create_groups_vargs+0xf4/0x100 device_create+0x7b/0xb0 bdi_register_va.part.13+0x58/0x2d0 bdi_register+0x9b/0xb0 init_mtd+0x62/0x171 [mtd] do_one_initcall+0x6c/0x3c0 do_init_module+0x58/0x222 load_module+0x268e/0x27d0 __do_sys_finit_module+0xd5/0x140 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd kobject_add_internal failed for mtd-0 with -EEXIST, don't try to register things with the same name in the same directory.Error registering mtd class or bdi: -17If init_mtdchar() fails in init_mtd(), mtd_bdi will not be unregistered,as a result, we can't load the mtd module again, to fix this by callingbdi_unregister(mtd_bdi) after out_procfs label.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl: Fix refcount leak in cxl_calc_capp_routingof_get_next_parent() returns a node pointer with refcount incremented,we should use of_node_put() on it when not need anymore.This function only calls of_node_put() in normal path,missing it in the error path.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:orangefs: Fix kmemleak in orangefs_sysfs_init()When insert and remove the orangefs module, there are kobjects memoryleaked as below:unreferenced object 0xffff88810f95af00 (size 64): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): a0 83 af 01 81 88 ff ff 08 af 95 0f 81 88 ff ff ................ 08 af 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000005a6e4dfe>] orangefs_sysfs_init+0x42/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0unreferenced object 0xffff88810f95ae80 (size 64): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): c8 90 0f 02 81 88 ff ff 88 ae 95 0f 81 88 ff ff ................ 88 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000001a4841fa>] orangefs_sysfs_init+0xc7/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0unreferenced object 0xffff88810f95ae00 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.511s) hex dump (first 32 bytes): 60 87 a1 00 81 88 ff ff 08 ae 95 0f 81 88 ff ff `............... 08 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000005915e797>] orangefs_sysfs_init+0x12b/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0unreferenced object 0xffff88810f95ad80 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.511s) hex dump (first 32 bytes): 78 90 0f 02 81 88 ff ff 88 ad 95 0f 81 88 ff ff x............... 88 ad 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000007a14eb35>] orangefs_sysfs_init+0x1ac/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0unreferenced object 0xffff88810f95ac00 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.531s) hex dump (first 32 bytes): e0 ff 67 02 81 88 ff ff 08 ac 95 0f 81 88 ff ff ..g............. 08 ac 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000001f38adcb>] orangefs_sysfs_init+0x291/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns: fix possible memory leak in hnae_ae_register()Inject fault while probing module, if device_register() fails,but the refcount of kobject is not decreased to 0, the nameallocated in dev_set_name() is leaked. Fix this by callingput_device(), so that name can be freed in callback functionkobject_cleanup().unreferenced object 0xffff00c01aba2100 (size 128): comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s) hex dump (first 32 bytes): 68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000034783f26>] slab_post_alloc_hook+0xa0/0x3e0 [<00000000748188f2>] __kmem_cache_alloc_node+0x164/0x2b0 [<00000000ab0743e8>] __kmalloc_node_track_caller+0x6c/0x390 [<000000006c0ffb13>] kvasprintf+0x8c/0x118 [<00000000fa27bfe1>] kvasprintf_const+0x60/0xc8 [<0000000083e10ed7>] kobject_set_name_vargs+0x3c/0xc0 [<000000000b87affc>] dev_set_name+0x7c/0xa0 [<000000003fd8fe26>] hnae_ae_register+0xcc/0x190 [hnae] [<00000000fe97edc9>] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf] [<00000000c36ff1eb>] hns_dsaf_probe+0x548/0x748 [hns_dsaf]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: vme_user: Fix possible UAF in tsi148_dma_list_addSmatch report warning as follows:drivers/staging/vme_user/vme_tsi148.c:1757 tsi148_dma_list_add() warn: '&entry->list' not removed from listIn tsi148_dma_list_add(), the error path "goto err_dma" will notremove entry->list from list->entries, but entry will be freed,then list traversal may cause UAF.Fix by removeing it from list->entries before free().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/wpcm450: Fix memory leak in wpcm450_aic_of_init()If of_iomap() failed, 'aic' should be freed before return. Otherwisethere is a memory leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl: fix possible null-ptr-deref in cxl_guest_init_afu|adapter()If device_register() fails in cxl_register_afu|adapter(), the deviceis not added, device_unregister() can not be called in the error path,otherwise it will cause a null-ptr-deref because of removing not addeddevice.As comment of device_register() says, it should use put_device() to giveup the reference in the error path. So split device_unregister() intodevice_del() and put_device(), then goes to put dev when register fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: netsec: fix error handling in netsec_register_mdio()If phy_device_register() fails, phy_device_free() need be called toput refcount, so memory of phy device and device name can be freedin callback function.If get_phy_device() fails, mdiobus_unregister() need be called,or it will cause warning in mdiobus_free() and kobject is leaked.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/gud: Fix UBSAN warningUBSAN complains about invalid value for bool:[ 101.165172] [drm] Initialized gud 1.0.0 20200422 for 2-3.2:1.0 on minor 1[ 101.213360] gud 2-3.2:1.0: [drm] fb1: guddrmfb frame buffer device[ 101.213426] usbcore: registered new interface driver gud[ 101.989431] ================================================================================[ 101.989441] UBSAN: invalid-load in linux/include/linux/iosys-map.h:253:9[ 101.989447] load of value 121 is not a valid value for type '_Bool'[ 101.989451] CPU: 1 PID: 455 Comm: kworker/1:6 Not tainted 5.18.0-rc5-gud-5.18-rc5 #3[ 101.989456] Hardware name: Hewlett-Packard HP EliteBook 820 G1/1991, BIOS L71 Ver. 01.44 04/12/2018[ 101.989459] Workqueue: events_long gud_flush_work [gud][ 101.989471] Call Trace:[ 101.989474] [ 101.989479] dump_stack_lvl+0x49/0x5f[ 101.989488] dump_stack+0x10/0x12[ 101.989493] ubsan_epilogue+0x9/0x3b[ 101.989498] __ubsan_handle_load_invalid_value.cold+0x44/0x49[ 101.989504] dma_buf_vmap.cold+0x38/0x3d[ 101.989511] ? find_busiest_group+0x48/0x300[ 101.989520] drm_gem_shmem_vmap+0x76/0x1b0 [drm_shmem_helper][ 101.989528] drm_gem_shmem_object_vmap+0x9/0xb [drm_shmem_helper][ 101.989535] drm_gem_vmap+0x26/0x60 [drm][ 101.989594] drm_gem_fb_vmap+0x47/0x150 [drm_kms_helper][ 101.989630] gud_prep_flush+0xc1/0x710 [gud][ 101.989639] ? _raw_spin_lock+0x17/0x40[ 101.989648] gud_flush_work+0x1e0/0x430 [gud][ 101.989653] ? __switch_to+0x11d/0x470[ 101.989664] process_one_work+0x21f/0x3f0[ 101.989673] worker_thread+0x200/0x3e0[ 101.989679] ? rescuer_thread+0x390/0x390[ 101.989684] kthread+0xfd/0x130[ 101.989690] ? kthread_complete_and_exit+0x20/0x20[ 101.989696] ret_from_fork+0x22/0x30[ 101.989706] [ 101.989708] ================================================================================The source of this warning is in iosys_map_clear() called fromdma_buf_vmap(). It conditionally sets values based on map->is_iomem. Theiosys_map variables are allocated uninitialized on the stack leading to->is_iomem having all kinds of values and not only 0/1.Fix this by zeroing the iosys_map variables.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: perf: marvell_cn10k: Fix hotplug callback leak in tad_pmu_init()tad_pmu_init() won't remove the callback added by cpuhp_setup_state_multi()when platform_driver_register() failed. Remove the callback bycpuhp_remove_multi_state() in fail path.Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus:arm-ccn: Prevent hotplug callback leak")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:power: supply: cw2015: Fix potential null-ptr-deref in cw_bat_probe()cw_bat_probe() calls create_singlethread_workqueue() and not checked theret value, which may return NULL. And a null-ptr-deref may happen:cw_bat_probe() create_singlethread_workqueue() # failed, cw_bat->wq is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-derefCheck the ret value and return -ENOMEM if it is NULL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ppp: associate skb with a device at txSyzkaller triggered flow dissector warning with the following:r0 = openat$ppp(0xffffffffffffff9c, &(0x7f0000000000), 0xc0802, 0x0)ioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &(0x7f00000000c0))ioctl$PPPIOCSACTIVE(r0, 0x40107446, &(0x7f0000000240)={0x2, &(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]})pwritev(r0, &(0x7f0000000040)=[{&(0x7f0000000140)='\x00!', 0x2}], 0x1, 0x0, 0x0)[ 9.485814] WARNING: CPU: 3 PID: 329 at net/core/flow_dissector.c:1016 __skb_flow_dissect+0x1ee0/0x1fa0[ 9.485929] skb_get_poff+0x53/0xa0[ 9.485937] bpf_skb_get_pay_offset+0xe/0x20[ 9.485944] ? ppp_send_frame+0xc2/0x5b0[ 9.485949] ? _raw_spin_unlock_irqrestore+0x40/0x60[ 9.485958] ? __ppp_xmit_process+0x7a/0xe0[ 9.485968] ? ppp_xmit_process+0x5b/0xb0[ 9.485974] ? ppp_write+0x12a/0x190[ 9.485981] ? do_iter_write+0x18e/0x2d0[ 9.485987] ? __import_iovec+0x30/0x130[ 9.485997] ? do_pwritev+0x1b6/0x240[ 9.486016] ? trace_hardirqs_on+0x47/0x50[ 9.486023] ? __x64_sys_pwritev+0x24/0x30[ 9.486026] ? do_syscall_64+0x3d/0x80[ 9.486031] ? entry_SYSCALL_64_after_hwframe+0x63/0xcdFlow dissector tries to find skb net namespace either via deviceor via socket. Neigher is set in ppp_send_frame, so let's manuallyuse ppp->dev.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: rds: don't hold sock lock when cancelling work from rds_tcp_reset_callbacks()syzbot is reporting lockdep warning at rds_tcp_reset_callbacks() [1], forcommit ac3615e7f3cffe2a ("RDS: TCP: Reduce code duplication inrds_tcp_reset_callbacks()") added cancel_delayed_work_sync() into a sectionprotected by lock_sock() without realizing that rds_send_xmit() might calllock_sock().We don't need to protect cancel_delayed_work_sync() using lock_sock(), foreven if rds_{send,recv}_worker() re-queued this work while __flush_work() from cancel_delayed_work_sync() was waiting for this work to complete,retried rds_{send,recv}_worker() is no-op due to the absence of RDS_CONN_UPbit.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmem: core: Fix memleak in nvmem_register()dev_set_name will alloc memory for nvmem->dev.kobj.name innvmem_register, when nvmem_validate_keepouts failed, nvmem'smemory will be freed and return, but nobody will free memoryfor nvmem->dev.kobj.name, there will be memleak, so movingnvmem_validate_keepouts() after device_register() and letthe device core deal with cleaning name in error cases.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Disable useless interrupt to avoid kernel panicThere is a hardware bug that the interrupt STMBUF_HALF may be triggeredafter or when disable interrupt.It may led to unexpected kernel panic.And interrupt STMBUF_HALF and STMBUF_RTND have no other effect.So disable them and the unused interrupts.meanwhile clear the interrupt status when disable interrupt.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: set generation before calling btrfs_clean_tree_block in btrfs_init_new_buffersyzbot is reporting uninit-value in btrfs_clean_tree_block() [1], forcommit bc877d285ca3dba2 ("btrfs: Deduplicate extent_buffer init code")missed that btrfs_set_header_generation() in btrfs_init_new_buffer() mustnot be moved to after clean_tree_block() because clean_tree_block() iscalling btrfs_header_generation() since commit 55c69072d6bd5be1 ("Btrfs:Fix extent_buffer usage when nodesize != leafsize").Since memzero_extent_buffer() will reset "struct btrfs_header" part, wecan't move btrfs_set_header_generation() to before memzero_extent_buffer().Just re-add btrfs_set_header_generation() before btrfs_clean_tree_block().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Fix __this_cpu_read() lockdep warning in rcu_force_quiescent_state()Running rcutorture with non-zero fqs_duration module parameter in akernel built with CONFIG_PREEMPTION=y results in the following splat:BUG: using __this_cpu_read() in preemptible [00000000]code: rcu_torture_fqs/398caller is __this_cpu_preempt_check+0x13/0x20CPU: 3 PID: 398 Comm: rcu_torture_fqs Not tainted 6.0.0-rc1-yoctodev-standard+Call Trace:dump_stack_lvl+0x5b/0x86dump_stack+0x10/0x16check_preemption_disabled+0xe5/0xf0__this_cpu_preempt_check+0x13/0x20rcu_force_quiescent_state.part.0+0x1c/0x170rcu_force_quiescent_state+0x1e/0x30rcu_torture_fqs+0xca/0x160? rcu_torture_boost+0x430/0x430kthread+0x192/0x1d0? kthread_complete_and_exit+0x30/0x30ret_from_fork+0x22/0x30The problem is that rcu_force_quiescent_state() uses __this_cpu_read()in preemptible code instead of the proper raw_cpu_read(). This committherefore changes __this_cpu_read() to raw_cpu_read().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: s5p-mfc: Clear workbit to handle error conditionDuring error on CLOSE_INSTANCE command, ctx_work_bits was not gettingcleared. During consequent mfc execution NULL pointer dereferencing ofthis context led to kernel panic. This patch fixes this issue by makingsure to clear ctx_work_bits always.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: fix missing unmap if z_erofs_get_extent_compressedlen() failsOtherwise, meta buffers could be leaked.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/arm_dmc620: Fix hotplug callback leak in dmc620_pmu_init()dmc620_pmu_init() won't remove the callback added bycpuhp_setup_state_multi() when platform_driver_register() failed. Removethe callback by cpuhp_remove_multi_state() in fail path.Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus:arm-ccn: Prevent hotplug callback leak")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: virtual_ncidev: Fix memory leak in virtual_nci_send()skb should be free in virtual_nci_send(), otherwise kmemleak will reportmemleak.Steps for reproduction (simulated in qemu): cd tools/testing/selftests/nci make ./nci_devBUG: memory leakunreferenced object 0xffff888107588000 (size 208): comm "nci_dev", pid 206, jiffies 4294945376 (age 368.248s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000008d94c8fd>] __alloc_skb+0x1da/0x290 [<00000000278bc7f8>] nci_send_cmd+0xa3/0x350 [<0000000081256a22>] nci_reset_req+0x6b/0xa0 [<000000009e721112>] __nci_request+0x90/0x250 [<000000005d556e59>] nci_dev_up+0x217/0x5b0 [<00000000e618ce62>] nfc_dev_up+0x114/0x220 [<00000000981e226b>] nfc_genl_dev_up+0x94/0xe0 [<000000009bb03517>] genl_family_rcv_msg_doit.isra.14+0x228/0x2d0 [<00000000b7f8c101>] genl_rcv_msg+0x35c/0x640 [<00000000c94075ff>] netlink_rcv_skb+0x11e/0x350 [<00000000440cfb1e>] genl_rcv+0x24/0x40 [<0000000062593b40>] netlink_unicast+0x43f/0x640 [<000000001d0b13cc>] netlink_sendmsg+0x73a/0xbf0 [<000000003272487f>] __sys_sendto+0x324/0x370 [<00000000ef9f1747>] __x64_sys_sendto+0xdd/0x1b0 [<000000001e437841>] do_syscall_64+0x3f/0x90
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: fix a signed-integer-overflow bug in tcp_add_backlog()The type of sk_rcvbuf and sk_sndbuf in struct sock is int, andin tcp_add_backlog(), the variable limit is caculated by addingsk_rcvbuf, sk_sndbuf and 64 * 1024, it may exceed the max valueof int and overflow. This patch reduces the limit budget byhalving the sndbuf to solve this issue since ACK packets are muchsmaller than the payload.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: Fix qmi_msg_handler data structure initializationqmi_msg_handler is required to be null terminated by QMI module.There might be a case where a handler for a msg id is not present in thehandlers array which can lead to infinite loop while searching the handlerand therefore out of bound access in qmi_invoke_handler().Hence update the initialization in qmi_msg_handler data structure.Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:of: overlay: fix null pointer dereferencing in find_dup_cset_node_entry() and find_dup_cset_prop()When kmalloc() fail to allocate memory in kasprintf(), fn_1 or fn_2 willbe NULL, and strcmp() will cause null pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: broadcom: bcm4908_enet: update TX stats after actual transmissionQueueing packets doesn't guarantee their transmission. Update TX statsafter hardware confirms consuming submitted data.This also fixes a possible race and NULL dereference.bcm4908_enet_start_xmit() could try to access skb after freeing it inthe bcm4908_enet_poll_tx().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix possible store tearing in neigh_periodic_work()While looking at a related syzbot report involving neigh_periodic_work(),I found that I forgot to add an annotation when deleting anRCU protected item from a list.Readers use rcu_deference(*np), we need to use eitherrcu_assign_pointer() or WRITE_ONCE() on writer sideto prevent store tearing.I use rcu_assign_pointer() to have lockdep support,this was the choice made in neigh_flush_dev().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()Including the transhdrlen in length is a problem when the packet ispartially filled (e.g. something like send(MSG_MORE) happened previously)when appending to an IPv4 or IPv6 packet as we don't want to repeat thetransport header or account for it twice. This can happen under somecircumstances, such as splicing into an L2TP socket.The symptom observed is a warning in __ip6_append_data(): WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800that occurs when MSG_SPLICE_PAGES is used to append more data to an alreadypartially occupied skbuff. The warning occurs when 'copy' is larger thanthe amount of data in the message iterator. This is because the requestedlength includes the transport header length when it shouldn't. This can betriggered by, for example: sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP); bind(sfd, ...); // ::1 connect(sfd, ...); // ::1 port 7 send(sfd, buffer, 4100, MSG_MORE); sendfile(sfd, dfd, NULL, 1024);Fix this by only adding transhdrlen into the length if the write queue isempty in l2tp_ip6_sendmsg(), analogously to how UDP does things.l2tp_ip_sendmsg() looks like it won't suffer from this problem as it buildsthe UDP packet itself.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: j1939: prevent deadlock by changing j1939_socks_lock to rwlockThe following 3 locks would race against each other, causing thedeadlock situation in the Syzbot bug report:- j1939_socks_lock- active_session_list_lock- sk_session_queue_lockA reasonable fix is to change j1939_socks_lock to an rwlock, since inthe rare situations where a write lock is required for the linked listthat j1939_socks_lock is protecting, the code does not attempt toacquire any more locks. This would break the circular lock dependency,where, for example, the current thread already locks j1939_socks_lockand attempts to acquire sk_session_queue_lock, and at the same time,another thread attempts to acquire j1939_socks_lock while holdingsk_session_queue_lock.NOTE: This patch along does not fix the unregister_netdevice bugreported by Syzbot; instead, it solves a deadlock situation to preparefor one or more further patches to actually fix the Syzbot bug, whichappears to be a reference counting problem within the j1939 codebase.[mkl: remove unrelated newline change]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Unmap the surface before resetting it on a plane stateSwitch to a new plane state requires unreferencing of all held surfaces.In the work required for mob cursors the mapped surfaces started beingcached but the variable indicating whether the surface is currentlymapped was not being reset. This leads to crashes as the duplicatedstate, incorrectly, indicates the that surface is mapped even whenno surface is present. That's because after unreferencing the surfaceit's perfectly possible for the plane to be backed by a bo instead of asurface.Reset the surface mapped flag when unreferencing the plane state surfaceto fix null derefs in cleanup. Fixes crashes in KDE KWin 6.0 on Wayland:Oops: 0000 [#1] PREEMPT SMP PTICPU: 4 PID: 2533 Comm: kwin_wayland Not tainted 6.7.0-rc3-vmwgfx #2Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f>RSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600RBP: ffff969d4143dc50 R08: 0000000000000000 R09: ffffb6b98216f920R10: 0000000000000003 R11: ffff969e7feb3b10 R12: 0000000000000000R13: 0000000000000000 R14: 000000000000027b R15: ffff969d49c9fc00FS: 00007f1e8f1b4180(0000) GS:ffff969e75f00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000028 CR3: 0000000104006004 CR4: 00000000003706f0Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? exc_page_fault+0x7f/0x180 ? asm_exc_page_fault+0x26/0x30 ? vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] drm_atomic_helper_cleanup_planes+0x9b/0xc0 commit_tail+0xd1/0x130 drm_atomic_helper_commit+0x11a/0x140 drm_atomic_commit+0x97/0xd0 ? __pfx___drm_printfn_info+0x10/0x10 drm_atomic_helper_update_plane+0xf5/0x160 drm_mode_cursor_universal+0x10e/0x270 drm_mode_cursor_common+0x102/0x230 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10 drm_ioctl_kernel+0xb2/0x110 drm_ioctl+0x26d/0x4b0 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10 ? __pfx_drm_ioctl+0x10/0x10 vmw_generic_ioctl+0xa4/0x110 [vmwgfx] __x64_sys_ioctl+0x94/0xd0 do_syscall_64+0x61/0xe0 ? __x64_sys_ioctl+0xaf/0xd0 ? syscall_exit_to_user_mode+0x2b/0x40 ? do_syscall_64+0x70/0xe0 ? __x64_sys_ioctl+0xaf/0xd0 ? syscall_exit_to_user_mode+0x2b/0x40 ? do_syscall_64+0x70/0xe0 ? exc_page_fault+0x7f/0x180 entry_SYSCALL_64_after_hwframe+0x6e/0x76RIP: 0033:0x7f1e93f279edCode: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff f>RSP: 002b:00007ffca0faf600 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 000055db876ed2c0 RCX: 00007f1e93f279edRDX: 00007ffca0faf6c0 RSI: 00000000c02464bb RDI: 0000000000000015RBP: 00007ffca0faf650 R08: 000055db87184010 R09: 0000000000000007R10: 000055db886471a0 R11: 0000000000000246 R12: 00007ffca0faf6c0R13: 00000000c02464bb R14: 0000000000000015 R15: 00007ffca0faf790 Modules linked in: snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_ine>CR2: 0000000000000028---[ end trace 0000000000000000 ]---RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f>RSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600RBP: ffff969d4143---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newerPrior to LLVM 15.0.0, LLVM's integrated assembler would incorrectlybyte-swap NOP when compiling for big-endian, and the resulting series ofbytes happened to match the encoding of FNMADD S21, S30, S0, S0.This went unnoticed until commit: 34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")Prior to that commit, the kernel would always enable the use of FPSIMDearly in boot when __cpu_setup() initialized CPACR_EL1, and so usage ofFNMADD within the kernel was not detected, but could result in thecorruption of user or kernel FPSIMD state.After that commit, the instructions happen to trap during boot prior toFPSIMD being detected and enabled, e.g.| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1| Hardware name: linux,dummy-virt (DT)| pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)| pc : __pi_strcmp+0x1c/0x150| lr : populate_properties+0xe4/0x254| sp : ffffd014173d3ad0| x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000| x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008| x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044| x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005| x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000| x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000| x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000| x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000| x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a| x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8| Kernel panic - not syncing: Unhandled exception| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1| Hardware name: linux,dummy-virt (DT)| Call trace:| dump_backtrace+0xec/0x108| show_stack+0x18/0x2c| dump_stack_lvl+0x50/0x68| dump_stack+0x18/0x24| panic+0x13c/0x340| el1t_64_irq_handler+0x0/0x1c| el1_abort+0x0/0x5c| el1h_64_sync+0x64/0x68| __pi_strcmp+0x1c/0x150| unflatten_dt_nodes+0x1e8/0x2d8| __unflatten_device_tree+0x5c/0x15c| unflatten_device_tree+0x38/0x50| setup_arch+0x164/0x1e0| start_kernel+0x64/0x38c| __primary_switched+0xbc/0xc4Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which iseither GNU as or LLVM's IAS 15.0.0 and newer, which contains the linkedcommit.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: support non-r10 register spill/fill to/from stack in precision trackingUse instruction (jump) history to record instructions that performedregister spill/fill to/from stack, regardless if this was done throughread-only r10 register, or any other register after copying r10 into it*and* potentially adjusting offset.To make this work reliably, we push extra per-instruction flags intoinstruction history, encoding stack slot index (spi) and stack framenumber in extra 10 bit flags we take away from prev_idx in instructionhistory. We don't touch idx field for maximum performance, as it'schecked most frequently during backtracking.This change removes basically the last remaining practical limitation ofprecision backtracking logic in BPF verifier. It fixes knowndeficiencies, but also opens up new opportunities to reduce number ofverified states, explored in the subsequent patches.There are only three differences in selftests' BPF object filesaccording to veristat, all in the positive direction (less states).File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)-------------------------------------- ------------- --------- --------- ------------- ---------- ---------- -------------test_cls_redirect_dynptr.bpf.linked3.o cls_redirect 2987 2864 -123 (-4.12%) 240 231 -9 (-3.75%)xdp_synproxy_kern.bpf.linked3.o syncookie_tc 82848 82661 -187 (-0.23%) 5107 5073 -34 (-0.67%)xdp_synproxy_kern.bpf.linked3.o syncookie_xdp 85116 84964 -152 (-0.18%) 5162 5130 -32 (-0.62%)Note, I avoided renaming jmp_history to more generic insn_hist tominimize number of lines changed and potential merge conflicts betweenbpf and bpf-next trees.Notice also cur_hist_entry pointer reset to NULL at the beginning ofinstruction verification loop. This pointer avoids the problem ofrelying on last jump history entry's insn_idx to determine whether wealready have entry for current instruction or not. It can happen that weadded jump history entry because current instruction is_jmp_point(), butalso we need to add instruction flags for stack access. In this case, wedon't want to entries, so we need to reuse last added entry, if it ispresent.Relying on insn_idx comparison has the same ambiguity problem as the onethat was fixed recently in [0], so we avoid that. [0] https://patchwork.kernel.org/project/netdevbpf/patch/20231110002638.4168352-3-andrii@kernel.org/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: caif: Fix use-after-free in cfusbl_device_notify()syzbot reported use-after-free in cfusbl_device_notify() [1]. Thiscauses a stack trace like below:BUG: KASAN: use-after-free in cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138Read of size 8 at addr ffff88807ac4e6f0 by task kworker/u4:6/1214CPU: 0 PID: 1214 Comm: kworker/u4:6 Not tainted 5.19.0-rc3-syzkaller-00146-g92f20ff72066 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: netns cleanup_netCall Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xeb/0x467 mm/kasan/report.c:313 print_report mm/kasan/report.c:429 [inline] kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491 cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138 notifier_call_chain+0xb5/0x200 kernel/notifier.c:87 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:1945 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline] call_netdevice_notifiers net/core/dev.c:1997 [inline] netdev_wait_allrefs_any net/core/dev.c:10227 [inline] netdev_run_todo+0xbc0/0x10f0 net/core/dev.c:10341 default_device_exit_batch+0x44e/0x590 net/core/dev.c:11334 ops_exit_list+0x125/0x170 net/core/net_namespace.c:167 cleanup_net+0x4ea/0xb00 net/core/net_namespace.c:594 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302 When unregistering a net device, unregister_netdevice_many_notify()sets the device's reg_state to NETREG_UNREGISTERING, calls notifierswith NETDEV_UNREGISTER, and adds the device to the todo list.Later on, devices in the todo list are processed by netdev_run_todo().netdev_run_todo() waits devices' reference count become 1 whilerebdoadcasting NETDEV_UNREGISTER notification.When cfusbl_device_notify() is called with NETDEV_UNREGISTER multipletimes, the parent device might be freed. This could cause UAF.Processing NETDEV_UNREGISTER multiple times also causes inbalance ofreference count for the module.This patch fixes the issue by accepting only first NETDEV_UNREGISTERnotification.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dw2102: Fix null-ptr-deref in dw2102_i2c_transfer()In dw2102_i2c_transfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach dw2102_i2c_transfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 950e252cb469("[media] dw2102: limit messages to buffer size")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix race on port outputassume the following setup on a single machine:1. An openvswitch instance with one bridge and default flows2. two network namespaces "server" and "client"3. two ovs interfaces "server" and "client" on the bridge4. for each ovs interface a veth pair with a matching name and 32 rx and tx queues5. move the ends of the veth pairs to the respective network namespaces6. assign ip addresses to each of the veth ends in the namespaces (needs to be the same subnet)7. start some http server on the server network namespace8. test if a client in the client namespace can reach the http serverwhen following the actions below the host has a chance of getting a cpustuck in a infinite loop:1. send a large amount of parallel requests to the http server (around 3000 curls should work)2. in parallel delete the network namespace (do not delete interfaces or stop the server, just kill the namespace)there is a low chance that this will cause the below kernel cpu stuckmessage. If this does not happen just retry.Below there is also the output of bpftrace for the functions mentionedin the output.The series of events happening here is:1. the network namespace is deleted calling `unregister_netdevice_many_notify` somewhere in the process2. this sets first `NETREG_UNREGISTERING` on both ends of the veth and then runs `synchronize_net`3. it then calls `call_netdevice_notifiers` with `NETDEV_UNREGISTER`4. this is then handled by `dp_device_event` which calls `ovs_netdev_detach_dev` (if a vport is found, which is the case for the veth interface attached to ovs)5. this removes the rx_handlers of the device but does not prevent packages to be sent to the device6. `dp_device_event` then queues the vport deletion to work in background as a ovs_lock is needed that we do not hold in the unregistration path7. `unregister_netdevice_many_notify` continues to call `netdev_unregister_kobject` which sets `real_num_tx_queues` to 08. port deletion continues (but details are not relevant for this issue)9. at some future point the background task deletes the vportIf after 7. but before 9. a packet is send to the ovs vport (which isnot deleted at this point in time) which forwards it to the`dev_queue_xmit` flow even though the device is unregistering.In `skb_tx_hash` (which is called in the `dev_queue_xmit`) path there isa while loop (if the packet has a rx_queue recorded) that is infinite if`dev->real_num_tx_queues` is zero.To prevent this from happening we update `do_output` to handle deviceswithout carrier the same as if the device is not found (which wouldbe the code path after 9. is done).Additionally we now produce a warning in `skb_tx_hash` if we will hitthe infinite loop.bpftrace (first word is function name):__dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6, reg_state: 2ovs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state: 2netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024netdev_rx_handler_unregister ret server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2dp_---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM: domains: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: set_page_extent_mapped after read_folio in btrfs_cont_expandWhile trying to get the subpage blocksize tests running, I hit thefollowing panic on generic/476 assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229 kernel BUG at fs/btrfs/subpage.c:229! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 1 PID: 1453 Comm: fsstress Not tainted 6.4.0-rc7+ #12 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023 pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_subpage_assert+0xbc/0xf0 lr : btrfs_subpage_assert+0xbc/0xf0 Call trace: btrfs_subpage_assert+0xbc/0xf0 btrfs_subpage_clear_checked+0x38/0xc0 btrfs_page_clear_checked+0x48/0x98 btrfs_truncate_block+0x5d0/0x6a8 btrfs_cont_expand+0x5c/0x528 btrfs_write_check.isra.0+0xf8/0x150 btrfs_buffered_write+0xb4/0x760 btrfs_do_write_iter+0x2f8/0x4b0 btrfs_file_write_iter+0x1c/0x30 do_iter_readv_writev+0xc8/0x158 do_iter_write+0x9c/0x210 vfs_iter_write+0x24/0x40 iter_file_splice_write+0x224/0x390 direct_splice_actor+0x38/0x68 splice_direct_to_actor+0x12c/0x260 do_splice_direct+0x90/0xe8 generic_copy_file_range+0x50/0x90 vfs_copy_file_range+0x29c/0x470 __arm64_sys_copy_file_range+0xcc/0x498 invoke_syscall.constprop.0+0x80/0xd8 do_el0_svc+0x6c/0x168 el0_svc+0x50/0x1b0 el0t_64_sync_handler+0x114/0x120 el0t_64_sync+0x194/0x198This happens because during btrfs_cont_expand we'll get a page, set itas mapped, and if it's not Uptodate we'll read it. However between theread and re-locking the page we could have called release_folio() on thepage, but left the page in the file mapping. release_folio() can clearthe page private, and thus further down we blow up when we go to modifythe subpage bits.Fix this by putting the set_page_extent_mapped() after the read. Thisis safe because read_folio() will call set_page_extent_mapped() beforeit does the read, and then if we clear page private but leave it on themapping we're completely safe re-setting set_page_extent_mapped(). Withthis patch I can now run generic/476 without panicing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: bdisp: Add missing check for create_workqueueAdd the check for the return value of the create_workqueuein order to avoid NULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix kernel crash due to null io->bioWe should return when io->bio is null before doing anything. Otherwise, panic.BUG: kernel NULL pointer dereference, address: 0000000000000010RIP: 0010:__submit_merged_write_cond+0x164/0x240 [f2fs]Call Trace: f2fs_submit_merged_write+0x1d/0x30 [f2fs] commit_checkpoint+0x110/0x1e0 [f2fs] f2fs_write_checkpoint+0x9f7/0xf00 [f2fs] ? __pfx_issue_checkpoint_thread+0x10/0x10 [f2fs] __checkpoint_and_complete_reqs+0x84/0x190 [f2fs] ? preempt_count_add+0x82/0xc0 ? __pfx_issue_checkpoint_thread+0x10/0x10 [f2fs] issue_checkpoint_thread+0x4c/0xf0 [f2fs] ? __pfx_autoremove_wake_function+0x10/0x10 kthread+0xff/0x130 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:recordmcount: Fix memory leaks in the uwrite functionCommon realloc mistake: 'file_append' nulled but not freed upon failure
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix BUG_ON condition in btrfs_cancel_balancePausing and canceling balance can race to interrupt balance lead to BUG_ONpanic in btrfs_cancel_balance. The BUG_ON condition in btrfs_cancel_balancedoes not take this race scenario into account.However, the race condition has no other side effects. We can fix that.Reproducing it with panic trace like this: kernel BUG at fs/btrfs/volumes.c:4618! RIP: 0010:btrfs_cancel_balance+0x5cf/0x6a0 Call Trace: ? do_nanosleep+0x60/0x120 ? hrtimer_nanosleep+0xb7/0x1a0 ? sched_core_clone_cookie+0x70/0x70 btrfs_ioctl_balance_ctl+0x55/0x70 btrfs_ioctl+0xa46/0xd20 __x64_sys_ioctl+0x7d/0xa0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Race scenario as follows: > mutex_unlock(&fs_info->balance_mutex); > -------------------- > .......issue pause and cancel req in another thread > -------------------- > ret = __btrfs_balance(fs_info); > > mutex_lock(&fs_info->balance_mutex); > if (ret == -ECANCELED && atomic_read(&fs_info->balance_pause_req)) { > btrfs_info(fs_info, "balance: paused"); > btrfs_exclop_balance(fs_info, BTRFS_EXCLOP_BALANCE_PAUSED); > }
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kernel/fail_function: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Fix device management cmd timeout flowIn the UFS error handling flow, the host will send a device management cmd(NOP OUT) to the device for link recovery. If this cmd times out andclearing the doorbell fails, ufshcd_wait_for_dev_cmd() will do nothing andreturn. hba->dev_cmd.complete struct is not set to NULL.When this happens, if cmd has been completed by device, then we will callcomplete() in __ufshcd_transfer_req_compl(). Because the complete struct isallocated on the stack, the following crash will occur: ipanic_die+0x24/0x38 [mrdump] die+0x344/0x748 arm64_notify_die+0x44/0x104 do_debug_exception+0x104/0x1e0 el1_dbg+0x38/0x54 el1_sync_handler+0x40/0x88 el1_sync+0x8c/0x140 queued_spin_lock_slowpath+0x2e4/0x3c0 __ufshcd_transfer_req_compl+0x3b0/0x1164 ufshcd_trc_handler+0x15c/0x308 ufshcd_host_reset_and_restore+0x54/0x260 ufshcd_reset_and_restore+0x28c/0x57c ufshcd_err_handler+0xeb8/0x1b6c process_one_work+0x288/0x964 worker_thread+0x4bc/0xc7c kthread+0x15c/0x264 ret_from_fork+0x10/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: xsk: Fix crash on regular rq reactivationWhen the regular rq is reactivated after the XSK socket is closedit could be reading stale cqes which eventually corrupts the rq.This leads to no more traffic being received on the regular rq and acrash on the next close or deactivation of the rq.Kal Cuttler Conely reported this issue as a crash on the releasepath when the xdpsock sample program is stopped (killed) and restartedin sequence while traffic is running.This patch flushes all cqes when during the rq flush. The cqe flushingis done in the reset state of the rq. mlx5e_rq_to_ready code is movedinto the flush function to allow for this.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:trace/blktrace: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: ULPI: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM: EM: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Protect rcu_print_task_exp_stall() ->exp_tasks accessFor kernels built with CONFIG_PREEMPT_RCU=y, the following scenario canresult in a NULL-pointer dereference: CPU1 CPU2rcu_preempt_deferred_qs_irqrestore rcu_print_task_exp_stall if (special.b.blocked) READ_ONCE(rnp->exp_tasks) != NULL raw_spin_lock_rcu_node np = rcu_next_node_entry(t, rnp) if (&t->rcu_node_entry == rnp->exp_tasks) WRITE_ONCE(rnp->exp_tasks, np) .... raw_spin_unlock_irqrestore_rcu_node raw_spin_lock_irqsave_rcu_node t = list_entry(rnp->exp_tasks->prev, struct task_struct, rcu_node_entry) (if rnp->exp_tasks is NULL, this will dereference a NULL pointer)The problem is that CPU2 accesses the rcu_node structure's->exp_tasksfield without holding the rcu_node structure's ->lock and CPU2 didnot observe CPU1's change to rcu_node structure's ->exp_tasks in time.Therefore, if CPU1 sets rcu_node structure's->exp_tasks pointer to NULL,then CPU2 might dereference that NULL pointer.This commit therefore holds the rcu_node structure's ->lock whileaccessing that structure's->exp_tasks field.[ paulmck: Apply Frederic Weisbecker feedback. ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: platform: mediatek: vpu: fix NULL ptr dereferenceIf pdev is NULL, then it is still dereferenced.This fixes this smatch warning:drivers/media/platform/mediatek/vpu/mtk_vpu.c:570 vpu_load_firmware() warn: address of NULL pointer 'pdev'
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: remove a BUG_ON in ext4_mb_release_group_pa()If a malicious fuzzer overwrites the ext4 superblock while it ismounted such that the s_first_data_block is set to a very largenumber, the calculation of the block group can underflow, and triggera BUG_ON check. Change this to be an ext4_warning so that we don'tcrash the kernel.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw88: fix memory leak in rtw_usb_probe()drivers/net/wireless/realtek/rtw88/usb.c:876 rtw_usb_probe()warn: 'hw' from ieee80211_alloc_hw() not released on lines: 811Fix this by modifying return to a goto statement.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: wait interruptibly for request completions on exitWHen the ring exits, cleanup is done and the final cancelation andwaiting on completions is done by io_ring_exit_work. That function isinvoked by kworker, which doesn't take any signals. Because of that, itdoesn't really matter if we wait for completions in TASK_INTERRUPTIBLEor TASK_UNINTERRUPTIBLE state. However, it does matter to the hung taskdetection checker!Normally we expect cancelations and completions to happen ratherquickly. Some test cases, however, will exit the ring and park theowning task stopped (eg via SIGSTOP). If the owning task needs to runtask_work to complete requests, then io_ring_exit_work won't make anyprogress until the task is runnable again. Hence io_ring_exit_work cantrigger the hung task detection, which is particularly problematic ifpanic-on-hung-task is enabled.As the ring exit doesn't take signals to begin with, have it waitinterruptibly rather than uninterruptibly. io_uring has a separatestuck-exit warning that triggers independently anyway, so we're notreally missing anything by making this switch.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: processor: Check for null return of devm_kzalloc() in fch_misc_setup()devm_kzalloc() may fail, clk_data->name might be NULL and willcause a NULL pointer dereference later.[ rjw: Subject and changelog edits ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: unmap and remove csa_va properlyRoot PD BO should be reserved before unmap and removea bo_va from VM otherwise lockdep will complain.v2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian)[14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu][14616.937096] Call Trace:[14616.937097] [14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu][14616.937187] drm_file_free+0x1d6/0x300 [drm][14616.937207] drm_close_helper.isra.0+0x62/0x70 [drm][14616.937220] drm_release+0x5e/0x100 [drm][14616.937234] __fput+0x9f/0x280[14616.937239] ____fput+0xe/0x20[14616.937241] task_work_run+0x61/0x90[14616.937246] exit_to_user_mode_prepare+0x215/0x220[14616.937251] syscall_exit_to_user_mode+0x2a/0x60[14616.937254] do_syscall_64+0x48/0x90[14616.937257] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:null_blk: Always check queue mode setting from configfsMake sure to check device queue mode in the null_validate_conf() andreturn error for NULL_Q_RQ as we don't allow legacy I/O path, withoutthis patch we get OOPs when queue mode is set to 1 from configfs,following are repro steps :-modprobe null_blk nr_devices=0mkdir config/nullb/nullb0echo 1 > config/nullb/nullb0/memory_backedecho 4096 > config/nullb/nullb0/blocksizeecho 20480 > config/nullb/nullb0/sizeecho 1 > config/nullb/nullb0/queue_modeecho 1 > config/nullb/nullb0/powerEntering kdb (current=0xffff88810acdd080, pid 2372) on processor 42 Oops: (null)due to oops @ 0xffffffffc041c329CPU: 42 PID: 2372 Comm: sh Tainted: G O N 6.3.0-rc5lblk+ #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014RIP: 0010:null_add_dev.part.0+0xd9/0x720 [null_blk]Code: 01 00 00 85 d2 0f 85 a1 03 00 00 48 83 bb 08 01 00 00 00 0f 85 f7 03 00 00 80 bb 62 01 00 00 00 48 8b 75 20 0f 85 6d 02 00 00 <48> 89 6e 60 48 8b 75 20 bf 06 00 00 00 e8 f5 37 2c c1 48 8b 75 20RSP: 0018:ffffc900052cbde0 EFLAGS: 00010246RAX: 0000000000000001 RBX: ffff88811084d800 RCX: 0000000000000001RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888100042e00RBP: ffff8881053d8200 R08: ffffc900052cbd68 R09: ffff888105db2000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002R13: ffff888104765200 R14: ffff88810eec1748 R15: ffff88810eec1740FS: 00007fd445fd1740(0000) GS:ffff8897dfc80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000060 CR3: 0000000166a00000 CR4: 0000000000350ee0DR0: ffffffff8437a488 DR1: ffffffff8437a489 DR2: ffffffff8437a48aDR3: ffffffff8437a48b DR6: 00000000ffff0ff0 DR7: 0000000000000400Call Trace: nullb_device_power_store+0xd1/0x120 [null_blk] configfs_write_iter+0xb4/0x120 vfs_write+0x2ba/0x3c0 ksys_write+0x5f/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcRIP: 0033:0x7fd4460c57a7Code: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24RSP: 002b:00007ffd3792a4a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fd4460c57a7RDX: 0000000000000002 RSI: 000055b43c02e4c0 RDI: 0000000000000001RBP: 000055b43c02e4c0 R08: 000000000000000a R09: 00007fd44615b4e0R10: 00007fd44615b3e0 R11: 0000000000000246 R12: 0000000000000002R13: 00007fd446198520 R14: 0000000000000002 R15: 00007fd446198700
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: reject invalid reloc tree root keys with stack dump[BUG]Syzbot reported a crash that an ASSERT() got triggered insideprepare_to_merge().That ASSERT() makes sure the reloc tree is properly pointed back by itssubvolume tree.[CAUSE]After more debugging output, it turns out we had an invalid reloc tree: BTRFS error (device loop1): reloc tree mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17Note the above root key is (TREE_RELOC_OBJECTID, ROOT_ITEM,QUOTA_TREE_OBJECTID), meaning it's a reloc tree for quota tree.But reloc trees can only exist for subvolumes, as for non-subvolumetrees, we just COW the involved tree block, no need to create a reloctree since those tree blocks won't be shared with other trees.Only subvolumes tree can share tree blocks with other trees (thus theyhave BTRFS_ROOT_SHAREABLE flag).Thus this new debug output proves my previous assumption that corruptedon-disk data can trigger that ASSERT().[FIX]Besides the dedicated fix and the graceful exit, also let tree-checker tocheck such root keys, to make sure reloc trees can only exist for subvolumes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: fix soft lockup in status_resyncstatus_resync() will calculate 'curr_resync - recovery_active' to showuser a progress bar like following:[============>........] resync = 61.4%'curr_resync' and 'recovery_active' is updated in md_do_sync(), andstatus_resync() can read them concurrently, hence it's possible that'curr_resync - recovery_active' can overflow to a huge number. In thiscase status_resync() will be stuck in the loop to print a large amountof '=', which will end up soft lockup.Fix the problem by setting 'resync' to MD_RESYNC_ACTIVE in this case,this way resync in progress will be reported to user.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Grab sas_dev lock when traversing the members of sas_dev.listWhen freeing slots in function slot_complete_v3_hw(), it is possible thatsas_dev.list is being traversed elsewhere, and it may trigger a NULLpointer exception, such as follows:==>cq thread ==>scsi_eh_6 ==>scsi_error_handler() ==>sas_eh_handle_sas_errors() ==>sas_scsi_find_task() ==>lldd_abort_task()==>slot_complete_v3_hw() ==>hisi_sas_abort_task() ==>hisi_sas_slot_task_free() ==>dereg_device_v3_hw() ==>list_del_init() ==>list_for_each_entry_safe()[ 7165.434918] sas: Enter sas_scsi_recover_host busy: 32 failed: 32[ 7165.434926] sas: trying to find task 0x00000000769b5ba5[ 7165.434927] sas: sas_scsi_find_task: aborting task 0x00000000769b5ba5[ 7165.434940] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000769b5ba5) aborted[ 7165.434964] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000c9f7aa07) ignored[ 7165.434965] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000e2a1cf01) ignored[ 7165.434968] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000[ 7165.434972] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000022d52d93) ignored[ 7165.434975] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000066a7516c) ignored[ 7165.434976] Mem abort info:[ 7165.434982] ESR = 0x96000004[ 7165.434991] Exception class = DABT (current EL), IL = 32 bits[ 7165.434992] SET = 0, FnV = 0[ 7165.434993] EA = 0, S1PTW = 0[ 7165.434994] Data abort info:[ 7165.434994] ISV = 0, ISS = 0x00000004[ 7165.434995] CM = 0, WnR = 0[ 7165.434997] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000f29543f2[ 7165.434998] [0000000000000000] pgd=0000000000000000[ 7165.435003] Internal error: Oops: 96000004 [#1] SMP[ 7165.439863] Process scsi_eh_6 (pid: 4109, stack limit = 0x00000000c43818d5)[ 7165.468862] pstate: 00c00009 (nzcv daif +PAN +UAO)[ 7165.473637] pc : dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw][ 7165.479443] lr : dereg_device_v3_hw+0x2c/0xa8 [hisi_sas_v3_hw][ 7165.485247] sp : ffff00001d623bc0[ 7165.488546] x29: ffff00001d623bc0 x28: ffffa027d03b9508[ 7165.493835] x27: ffff80278ed50af0 x26: ffffa027dd31e0a8[ 7165.499123] x25: ffffa027d9b27f88 x24: ffffa027d9b209f8[ 7165.504411] x23: ffffa027c45b0d60 x22: ffff80278ec07c00[ 7165.509700] x21: 0000000000000008 x20: ffffa027d9b209f8[ 7165.514988] x19: ffffa027d9b27f88 x18: ffffffffffffffff[ 7165.520276] x17: 0000000000000000 x16: 0000000000000000[ 7165.525564] x15: ffff0000091d9708 x14: ffff0000093b7dc8[ 7165.530852] x13: ffff0000093b7a23 x12: 6e7265746e692067[ 7165.536140] x11: 0000000000000000 x10: 0000000000000bb0[ 7165.541429] x9 : ffff00001d6238f0 x8 : ffffa027d877af00[ 7165.546718] x7 : ffffa027d6329600 x6 : ffff7e809f58ca00[ 7165.552006] x5 : 0000000000001f8a x4 : 000000000000088e[ 7165.557295] x3 : ffffa027d9b27fa8 x2 : 0000000000000000[ 7165.562583] x1 : 0000000000000000 x0 : 000000003000188e[ 7165.567872] Call trace:[ 7165.570309] dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw][ 7165.575775] hisi_sas_abort_task+0x248/0x358 [hisi_sas_main][ 7165.581415] sas_eh_handle_sas_errors+0x258/0x8e0 [libsas][ 7165.586876] sas_scsi_recover_host+0x134/0x458 [libsas][ 7165.592082] scsi_error_handler+0xb4/0x488[ 7165.596163] kthread+0x134/0x138[ 7165.599380] ret_from_fork+0x10/0x18[ 7165.602940] Code: d5033e9f b9000040 aa0103e2 eb03003f (f9400021)[ 7165.609004] kernel fault(0x1) notification starting on CPU 75[ 7165.700728] ---[ end trace fc042cbbea224efc ]---[ 7165.705326] Kernel panic - not syncing: Fatal exceptionTo fix the issue, grab sas_dev lock when traversing the members ofsas_dev.list in dereg_device_v3_hw() and hisi_sas_release_tasks() to avoidconcurrency of adding and deleting member. When ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Don't tx before switchdev is fully configuredThere is possibility that ice_eswitch_port_start_xmit might becalled while some resources are still not allocated which mightcause NULL pointer dereference. Fix this by checking if switchdevconfiguration was finished.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: output extra debug info if we failed to find an inline backref[BUG]Syzbot reported several warning triggered insidelookup_inline_extent_backref().[CAUSE]As usual, the reproducer doesn't reliably trigger locally here, but atleast we know the WARN_ON() is triggered when an inline backref can notbe found, and it can only be triggered when @insert is true. (I.e.inserting a new inline backref, which means the backref should alreadyexist)[ENHANCEMENT]After the WARN_ON(), dump all the parameters and the extent treeleaf to help debug.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Zero padding when dumping algos and encapWhen copying data to user-space we should ensure that only validdata is copied over. Padding in structures may be filled withrandom (possibly sensitve) data and should never be given directlyto user-space.This patch fixes the copying of xfrm algorithms and the encaptemplate in xfrm_user so that padding is zeroed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: fq_pie: avoid stalls in fq_pie_timer()When setting a high number of flows (limit being 65536),fq_pie_timer() is currently using too much time as syzbot reported.Add logic to yield the cpu every 2048 flows (less than 150 usecon debug kernels).It should also help by not blocking qdisc fast paths for too long.Worst case (65536 flows) would need 31 jiffies for a complete scan.Relevant extract from syzbot report:rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 0-.... } 2663 jiffies s: 873 root: 0x1/.rcu: blocking rcu_node structures (internal RCU debug):Sending NMI from CPU 1 to CPUs 0:NMI backtrace for cpu 0CPU: 0 PID: 5177 Comm: syz-executor273 Not tainted 6.5.0-syzkaller-00453-g727dbda16b83 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline]RIP: 0010:write_comp_data+0x21/0x90 kernel/kcov.c:236Code: 2e 0f 1f 84 00 00 00 00 00 65 8b 05 01 b2 7d 7e 49 89 f1 89 c6 49 89 d2 81 e6 00 01 00 00 49 89 f8 65 48 8b 14 25 80 b9 03 00
00 01 ff 00 74 0e 85 f6 74 59 8b 82 04 16 00 00 85 c0 74 4f 8bRSP: 0018:ffffc90000007bb8 EFLAGS: 00000206RAX: 0000000000000101 RBX: ffffc9000dc0d140 RCX: ffffffff885893b0RDX: ffff88807c075940 RSI: 0000000000000100 RDI: 0000000000000001RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: ffffc9000dc0d178R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 0000555555d54380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f6b442f6130 CR3: 000000006fe1c000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: pie_calculate_probability+0x480/0x850 net/sched/sch_pie.c:415 fq_pie_timer+0x1da/0x4f0 net/sched/sch_fq_pie.c:387 call_timer_fn+0x1a0/0x580 kernel/time/timer.c:1700
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:um: vector: Fix memory leak in vector_configIf the return value of the uml_parse_vector_ifspec function is NULL,we should call kfree(params) to prevent memory leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: Fix potential array out-of-bounds in decoder queue_setupvariable *nplanes is provided by user via system call argument. Thepossible value of q_data->fmt->num_planes is 1-3, while the valueof *nplanes can be 1-8. The array access by index i can cause arrayout-of-bounds.Fix this bug by checking *nplanes against the array size.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/irq-mvebu-gicp: Fix refcount leak in mvebu_gicp_probeof_irq_find_parent() returns a node pointer with refcount incremented,We should use of_node_put() on it when not needed anymore.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_syncUse-after-free can occur in hci_disconnect_all_sync if a connection isdeleted by concurrent processing of a controller event.To prevent this the code now tries to iterate over the list backwardsto ensure the links are cleanup before its parents, also it no longerrelies on a cursor, instead it always uses the last element sincehci_abort_conn_sync is guaranteed to call hci_conn_del.UAF crash log:==================================================================BUG: KASAN: slab-use-after-free in hci_set_powered_sync(net/bluetooth/hci_sync.c:5424) [bluetooth]Read of size 8 at addr ffff888009d9c000 by task kworker/u9:0/124CPU: 0 PID: 124 Comm: kworker/u9:0 Tainted: G W6.5.0-rc1+ #10Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS1.16.2-1.fc38 04/01/2014Workqueue: hci0 hci_cmd_sync_work [bluetooth]Call Trace: dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0xdd/0x160 ? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth] kasan_report+0xa6/0xe0 ? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth] ? __pfx_set_powered_sync+0x10/0x10 [bluetooth] hci_set_powered_sync+0x2c9/0x4a0 [bluetooth] ? __pfx_hci_set_powered_sync+0x10/0x10 [bluetooth] ? __pfx_lock_release+0x10/0x10 ? __pfx_set_powered_sync+0x10/0x10 [bluetooth] hci_cmd_sync_work+0x137/0x220 [bluetooth] process_one_work+0x526/0x9d0 ? __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? mark_held_locks+0x1a/0x90 worker_thread+0x92/0x630 ? __pfx_worker_thread+0x10/0x10 kthread+0x196/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 Allocated by task 1782: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x8f/0xa0 hci_conn_add+0xa5/0xa80 [bluetooth] hci_bind_cis+0x881/0x9b0 [bluetooth] iso_connect_cis+0x121/0x520 [bluetooth] iso_sock_connect+0x3f6/0x790 [bluetooth] __sys_connect+0x109/0x130 __x64_sys_connect+0x40/0x50 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8Freed by task 695: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2b/0x50 __kasan_slab_free+0x10a/0x180 __kmem_cache_free+0x14d/0x2e0 device_release+0x5d/0xf0 kobject_put+0xdf/0x270 hci_disconn_complete_evt+0x274/0x3a0 [bluetooth] hci_event_packet+0x579/0x7e0 [bluetooth] hci_rx_work+0x287/0xaa0 [bluetooth] process_one_work+0x526/0x9d0 worker_thread+0x92/0x630 kthread+0x196/0x1e0 ret_from_fork+0x2c/0x50==================================================================
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mt76: mt7921: don't assume adequate headroom for SDIO headersmt7921_usb_sdio_tx_prepare_skb() calls mt7921_usb_sdio_write_txwi() andmt7921_skb_add_usb_sdio_hdr(), both of which blindly assume thatadequate headroom will be available in the passed skb. This assumptiontypically is satisfied when the skb was allocated in the net core fortransmission via the mt7921 netdev (although even that is only anoptimization and is not strictly guaranteed), but the assumption issometimes not satisfied when the skb originated in the receive path ofanother netdev and was passed through to the mt7921, such as by thebridge layer. Blindly prepending bytes to an skb is always wrong.This commit introduces a call to skb_cow_head() before the call tomt7921_usb_sdio_write_txwi() in mt7921_usb_sdio_tx_prepare_skb() toensure that at least MT_SDIO_TXD_SIZE + MT_SDIO_HDR_SIZE bytes can bepushed onto the skb.Without this fix, I can trivially cause kernel panics by bridging anMT7921AU-based USB 802.11ax interface with an Ethernet interface on anIntel Atom-based x86 system using its onboard RTL8169 PCI Ethernetadapter and also on an ARM-based Raspberry Pi 1 using its onboardSMSC9512 USB Ethernet adapter. Note that the panics do not occur inevery system configuration, as they occur only if the receiving netdevleaves less headroom in its received skbs than the mt7921 needs for itsSDIO headers.Here is an example stack trace of this panic on Raspberry Pi OS Lite2023-02-21 running kernel 6.1.24+ [1]: skb_panic from skb_push+0x44/0x48 skb_push from mt7921_usb_sdio_tx_prepare_skb+0xd4/0x190 [mt7921_common] mt7921_usb_sdio_tx_prepare_skb [mt7921_common] from mt76u_tx_queue_skb+0x94/0x1d0 [mt76_usb] mt76u_tx_queue_skb [mt76_usb] from __mt76_tx_queue_skb+0x4c/0xc8 [mt76] __mt76_tx_queue_skb [mt76] from mt76_txq_schedule.part.0+0x13c/0x398 [mt76] mt76_txq_schedule.part.0 [mt76] from mt76_txq_schedule_all+0x24/0x30 [mt76] mt76_txq_schedule_all [mt76] from mt7921_tx_worker+0x58/0xf4 [mt7921_common] mt7921_tx_worker [mt7921_common] from __mt76_worker_fn+0x9c/0xec [mt76] __mt76_worker_fn [mt76] from kthread+0xbc/0xe0 kthread from ret_from_fork+0x14/0x34After this fix, bridging the mt7921 interface works fine on both of mypreviously problematic systems.[1] https://github.com/raspberrypi/firmware/tree/5c276f55a4b21345cd4d6200a504ee991851ff7a
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Improve page fault error reportingIf IOMMU domain for device group is not setup properly then we may hitIOMMU page fault. Current page fault handler assumes that domain isalways setup and it will hit NULL pointer derefence (see below sample log).Lets check whether domain is setup or not and log appropriate message.Sample log:---------- amdgpu 0000:00:01.0: amdgpu: SE 1, SH per SE 1, CU per SH 8, active_cu_number 6 BUG: kernel NULL pointer dereference, address: 0000000000000058 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 2 PID: 56 Comm: irq/24-AMD-Vi Not tainted 6.2.0-rc2+ #89 Hardware name: xxx RIP: 0010:report_iommu_fault+0x11/0x90 [...] Call Trace: amd_iommu_int_thread+0x60c/0x760 ? __pfx_irq_thread_fn+0x10/0x10 irq_thread_fn+0x1f/0x60 irq_thread+0xea/0x1a0 ? preempt_count_add+0x6a/0xa0 ? __pfx_irq_thread_dtor+0x10/0x10 ? __pfx_irq_thread+0x10/0x10 kthread+0xe9/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 [joro: Edit commit message]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: Fix uninitialized number of lanesIt is not possible to set the number of lanes when setting link modesusing the legacy IOCTL ethtool interface. Since 'structethtool_link_ksettings' is not initialized in this path, drivers receivean uninitialized number of lanes in 'structethtool_link_ksettings::lanes'.When this information is later queried from drivers, it results in theethtool code making decisions based on uninitialized memory, leading tothe following KMSAN splat [1]. In practice, this most likely onlyhappens with the tun driver that simply returns whatever it got in theset operation.As far as I can tell, this uninitialized memory is not leaked to userspace thanks to the 'ethtool_ops->cap_link_lanes_supported' check inlinkmodes_prepare_data().Fix by initializing the structure in the IOCTL path. Did not find anymore call sites that pass an uninitialized structure when calling'ethtool_ops::set_link_ksettings()'.[1]BUG: KMSAN: uninit-value in ethnl_update_linkmodes net/ethtool/linkmodes.c:273 [inline]BUG: KMSAN: uninit-value in ethnl_set_linkmodes+0x190b/0x19d0 net/ethtool/linkmodes.c:333 ethnl_update_linkmodes net/ethtool/linkmodes.c:273 [inline] ethnl_set_linkmodes+0x190b/0x19d0 net/ethtool/linkmodes.c:333 ethnl_default_set_doit+0x88d/0xde0 net/ethtool/netlink.c:640 genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline] genl_rcv_msg+0x141a/0x14c0 net/netlink/genetlink.c:1065 netlink_rcv_skb+0x3f8/0x750 net/netlink/af_netlink.c:2577 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0xf41/0x1270 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x127d/0x1430 net/netlink/af_netlink.c:1942 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] ____sys_sendmsg+0xa24/0xe40 net/socket.c:2501 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2555 __sys_sendmsg net/socket.c:2584 [inline] __do_sys_sendmsg net/socket.c:2593 [inline] __se_sys_sendmsg net/socket.c:2591 [inline] __x64_sys_sendmsg+0x36b/0x540 net/socket.c:2591 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was stored to memory at: tun_get_link_ksettings+0x37/0x60 drivers/net/tun.c:3544 __ethtool_get_link_ksettings+0x17b/0x260 net/ethtool/ioctl.c:441 ethnl_set_linkmodes+0xee/0x19d0 net/ethtool/linkmodes.c:327 ethnl_default_set_doit+0x88d/0xde0 net/ethtool/netlink.c:640 genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline] genl_rcv_msg+0x141a/0x14c0 net/netlink/genetlink.c:1065 netlink_rcv_skb+0x3f8/0x750 net/netlink/af_netlink.c:2577 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0xf41/0x1270 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x127d/0x1430 net/netlink/af_netlink.c:1942 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] ____sys_sendmsg+0xa24/0xe40 net/socket.c:2501 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2555 __sys_sendmsg net/socket.c:2584 [inline] __do_sys_sendmsg net/socket.c:2593 [inline] __se_sys_sendmsg net/socket.c:2591 [inline] __x64_sys_sendmsg+0x36b/0x540 net/socket.c:2591 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was stored to memory at: tun_set_link_ksettings+0x37/0x60 drivers/net/tun.c:3553 ethtool_set_link_ksettings+0x600/0x690 net/ethtool/ioctl.c:609 __dev_ethtool net/ethtool/ioctl.c:3024 [inline] dev_ethtool+0x1db9/0x2a70 net/ethtool/ioctl.c:3078 dev_ioctl+0xb07/0x1270 net/core/dev_ioctl.c:524 sock_do_ioctl+0x295/0x540 net/socket.c:1213 sock_i---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: api - Use work queue in crypto_destroy_instanceThe function crypto_drop_spawn expects to be called in processcontext. However, when an instance is unregistered while it stillhas active users, the last user may cause the instance to be freedin atomic context.Fix this by delaying the freeing to a work queue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: clocking-wizard: Fix Oops in clk_wzrd_register_divider()Smatch detected this potential error pointer dereferenceclk_wzrd_register_divider(). If devm_clk_hw_register() fails thenit sets "hw" to an error pointer and then dereferences it on thenext line. Return the error directly instead.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: release crypto keyslot before reporting I/O completeOnce all I/O using a blk_crypto_key has completed, filesystems can callblk_crypto_evict_key(). However, the block layer currently doesn't callblk_crypto_put_keyslot() until the request is being freed, which happensafter upper layers have been told (via bio_endio()) the I/O hascompleted. This causes a race condition where blk_crypto_evict_key()can see 'slot_refs != 0' without there being an actual bug.This makes __blk_crypto_evict_key() hit the'WARN_ON_ONCE(atomic_read(&slot->slot_refs) != 0)' and return withoutdoing anything, eventually causing a use-after-free inblk_crypto_reprogram_all_keys(). (This is a very rare bug and has onlybeen seen when per-file keys are being used with fscrypt.)There are two options to fix this: either release the keyslot beforebio_endio() is called on the request's last bio, or make__blk_crypto_evict_key() ignore slot_refs. Let's go with the firstsolution, since it preserves the ability to report bugs (viaWARN_ON_ONCE) where a key is evicted while still in-use.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:posix-timers: Prevent RT livelock in itimer_delete()itimer_delete() has a retry loop when the timer is concurrently expired. Onnon-RT kernels this just spin-waits until the timer callback has completed,except for posix CPU timers which have HAVE_POSIX_CPU_TIMERS_TASK_WORKenabled.In that case and on RT kernels the existing task could live lock whenpreempting the task which does the timer delivery.Replace spin_unlock() with an invocation of timer_wait_running() to handleit the same way as the other retry loops in the posix timer code.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: lib/mpi - avoid null pointer deref in mpi_cmp_ui()During NVMeTCP Authentication a controller can trigger a kerneloops by specifying the 8192 bit Diffie Hellman group and passinga correctly sized, but zeroed Diffie Hellamn value.mpi_cmp_ui() was detecting this if the second parameter was 0,but 1 is passed from dh_is_pubkey_valid(). This causes the nullpointer u->d to be dereferenced towards the end of mpi_cmp_ui()
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: Ignore frags from uninitialized peer in dp.When max virtual ap interfaces are configured in all the bands withACS and hostapd restart is done every 60s, a crash is observed atrandom times.In this certain scenario, a fragmented packet is received forself peer, for which rx_tid and rx_frags are not initialized indatapath. While handling this fragment, crash is observed as therx_frag list is uninitialised and when we walk inath11k_dp_rx_h_sort_frags, skb null leads to exception.To address this, before processing received fragments we checkdp_setup_done flag is set to ensure that peer has completed itsdp peer setup for fragment queue, else ignore processing thefragments.Call trace: ath11k_dp_process_rx_err+0x550/0x1084 [ath11k] ath11k_dp_service_srng+0x70/0x370 [ath11k] 0xffffffc009693a04 __napi_poll+0x30/0xa4 net_rx_action+0x118/0x270 __do_softirq+0x10c/0x244 irq_exit+0x64/0xb4 __handle_domain_irq+0x88/0xac gic_handle_irq+0x74/0xbc el1_irq+0xf0/0x1c0 arch_cpu_idle+0x10/0x18 do_idle+0x104/0x248 cpu_startup_entry+0x20/0x64 rest_init+0xd0/0xdc arch_call_rest_init+0xc/0x14 start_kernel+0x480/0x4b8 Code: f9400281 f94066a2 91405021 b94a0023 (f9406401)Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block/rq_qos: protect rq_qos apis with a new lockcommit 50e34d78815e ("block: disable the elevator int del_gendisk")move rq_qos_exit() from disk_release() to del_gendisk(), this willintroduce some problems:1) If rq_qos_add() is triggered by enabling iocost/iolatency through cgroupfs, then it can concurrent with del_gendisk(), it's not safe to write 'q->rq_qos' concurrently.2) Activate cgroup policy that is relied on rq_qos will call rq_qos_add() and blkcg_activate_policy(), and if rq_qos_exit() is called in the middle, null-ptr-dereference will be triggered in blkcg_activate_policy().3) blkg_conf_open_bdev() can call blkdev_get_no_open() first to find the disk, then if rq_qos_exit() from del_gendisk() is done before rq_qos_add(), then memory will be leaked.This patch add a new disk level mutex 'rq_qos_mutex':1) The lock will protect rq_qos_exit() directly.2) For wbt that doesn't relied on blk-cgroup, rq_qos_add() can only be called from disk initialization for now because wbt can't be destructed until rq_qos_exit(), so it's safe not to protect wbt for now. Hoever, in case that rq_qos dynamically destruction is supported in the furture, this patch also protect rq_qos_add() from wbt_init() directly, this is enough because blk-sysfs already synchronize writers with disk removal.3) For iocost and iolatency, in order to synchronize disk removal and cgroup configuration, the lock is held after blkdev_get_no_open() from blkg_conf_open_bdev(), and is released in blkg_conf_exit(). In order to fix the above memory leak, disk_live() is checked after holding the new lock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: annotate lockless accesses to nlk->max_recvmsg_lensyzbot reported a data-race in data-race in netlink_recvmsg() [1]Indeed, netlink_recvmsg() can be run concurrently,and netlink_dump() also needs protection.[1]BUG: KCSAN: data-race in netlink_recvmsg / netlink_recvmsgread to 0xffff888141840b38 of 8 bytes by task 23057 on cpu 0:netlink_recvmsg+0xea/0x730 net/netlink/af_netlink.c:1988sock_recvmsg_nosec net/socket.c:1017 [inline]sock_recvmsg net/socket.c:1038 [inline]__sys_recvfrom+0x1ee/0x2e0 net/socket.c:2194__do_sys_recvfrom net/socket.c:2212 [inline]__se_sys_recvfrom net/socket.c:2208 [inline]__x64_sys_recvfrom+0x78/0x90 net/socket.c:2208do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdwrite to 0xffff888141840b38 of 8 bytes by task 23037 on cpu 1:netlink_recvmsg+0x114/0x730 net/netlink/af_netlink.c:1989sock_recvmsg_nosec net/socket.c:1017 [inline]sock_recvmsg net/socket.c:1038 [inline]____sys_recvmsg+0x156/0x310 net/socket.c:2720___sys_recvmsg net/socket.c:2762 [inline]do_recvmmsg+0x2e5/0x710 net/socket.c:2856__sys_recvmmsg net/socket.c:2935 [inline]__do_sys_recvmmsg net/socket.c:2958 [inline]__se_sys_recvmmsg net/socket.c:2951 [inline]__x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x0000000000000000 -> 0x0000000000001000Reported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 23037 Comm: syz-executor.2 Not tainted 6.3.0-rc4-syzkaller-00195-g5a57b48fdfcb #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: Fix error handling for SOCK_DGRAM in kcm_sendmsg().syzkaller found a memory leak in kcm_sendmsg(), and commit c821a88bd720("kcm: Fix memory leak in error path of kcm_sendmsg()") suppressed it byupdating kcm_tx_msg(head)->last_skb if partial data is copied so that thefollowing sendmsg() will resume from the skb.However, we cannot know how many bytes were copied when we get the error.Thus, we could mess up the MSG_MORE queue.When kcm_sendmsg() fails for SOCK_DGRAM, we should purge the queue as wedo so for UDP by udp_flush_pending_frames().Even without this change, when the error occurred, the following sendmsg()resumed from a wrong skb and the queue was messed up. However, we haveyet to get such a report, and only syzkaller stumbled on it. So, thiscan be changed safely.Note this does not change SOCK_SEQPACKET behaviour.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: read sk->sk_family once in sk_mc_loop()syzbot is playing with IPV6_ADDRFORM quite a lot these days,and managed to hit the WARN_ON_ONCE(1) in sk_mc_loop()We have many more similar issues to fix.WARNING: CPU: 1 PID: 1593 at net/core/sock.c:782 sk_mc_loop+0x165/0x260Modules linked in:CPU: 1 PID: 1593 Comm: kworker/1:3 Not tainted 6.1.40-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023Workqueue: events_power_efficient gc_workerRIP: 0010:sk_mc_loop+0x165/0x260 net/core/sock.c:782Code: 34 1b fd 49 81 c7 18 05 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 20 00 74 08 4c 89 ff e8 25 36 6d fd 4d 8b 37 eb 13 e8 db 33 1b fd <0f> 0b b3 01 eb 34 e8 d0 33 1b fd 45 31 f6 49 83 c6 38 4c 89 f0 48RSP: 0018:ffffc90000388530 EFLAGS: 00010246RAX: ffffffff846d9b55 RBX: 0000000000000011 RCX: ffff88814f884980RDX: 0000000000000102 RSI: ffffffff87ae5160 RDI: 0000000000000011RBP: ffffc90000388550 R08: 0000000000000003 R09: ffffffff846d9a65R10: 0000000000000002 R11: ffff88814f884980 R12: dffffc0000000000R13: ffff88810dbee000 R14: 0000000000000010 R15: ffff888150084000FS: 0000000000000000(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000180 CR3: 000000014ee5b000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:[] ip6_finish_output2+0x33f/0x1ae0 net/ipv6/ip6_output.c:83[] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline][] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211[] NF_HOOK_COND include/linux/netfilter.h:298 [inline][] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232[] dst_output include/net/dst.h:444 [inline][] ip6_local_out+0x10f/0x140 net/ipv6/output_core.c:161[] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:483 [inline][] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline][] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline][] ipvlan_queue_xmit+0x1174/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677[] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229[] netdev_start_xmit include/linux/netdevice.h:4925 [inline][] xmit_one net/core/dev.c:3644 [inline][] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660[] sch_direct_xmit+0x2a0/0x9c0 net/sched/sch_generic.c:342[] qdisc_restart net/sched/sch_generic.c:407 [inline][] __qdisc_run+0xb13/0x1e70 net/sched/sch_generic.c:415[] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125[] net_tx_action+0x7ac/0x940 net/core/dev.c:5247[] __do_softirq+0x2bd/0x9bd kernel/softirq.c:599[] invoke_softirq kernel/softirq.c:430 [inline][] __irq_exit_rcu+0xc8/0x170 kernel/softirq.c:683[] irq_exit_rcu+0x9/0x20 kernel/softirq.c:695
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix skb refcnt race after locking changesThere is a race where skb's from the sk_psock_backlog can be referencedafter userspace side has already skb_consumed() the sk_buff and its refcntdropped to zer0 causing use after free.The flow is the following: while ((skb = skb_peek(&psock->ingress_skb)) sk_psock_handle_Skb(psock, skb, ..., ingress) if (!ingress) ... sk_psock_skb_ingress sk_psock_skb_ingress_enqueue(skb) msg->skb = skb sk_psock_queue_msg(psock, msg) skb_dequeue(&psock->ingress_skb)The sk_psock_queue_msg() puts the msg on the ingress_msg queue. This iswhat the application reads when recvmsg() is called. An application canread this anytime after the msg is placed on the queue. The recvmsg hookwill also read msg->skb and then after user space reads the msg will callconsume_skb(skb) on it effectively free'ing it.But, the race is in above where backlog queue still has a reference tothe skb and calls skb_dequeue(). If the skb_dequeue happens after theuser reads and free's the skb we have a use after free.The !ingress case does not suffer from this problem because it usessendmsg_*(sk, msg) which does not pass the sk_buff further down thestack.The following splat was observed with 'test_progs -t sockmap_listen': [ 1022.710250][ T2556] general protection fault, ... [...] [ 1022.712830][ T2556] Workqueue: events sk_psock_backlog [ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80 [ 1022.713653][ T2556] Code: ... [...] [ 1022.720699][ T2556] Call Trace: [ 1022.720984][ T2556] [ 1022.721254][ T2556] ? die_addr+0x32/0x80^M [ 1022.721589][ T2556] ? exc_general_protection+0x25a/0x4b0 [ 1022.722026][ T2556] ? asm_exc_general_protection+0x22/0x30 [ 1022.722489][ T2556] ? skb_dequeue+0x4c/0x80 [ 1022.722854][ T2556] sk_psock_backlog+0x27a/0x300 [ 1022.723243][ T2556] process_one_work+0x2a7/0x5b0 [ 1022.723633][ T2556] worker_thread+0x4f/0x3a0 [ 1022.723998][ T2556] ? __pfx_worker_thread+0x10/0x10 [ 1022.724386][ T2556] kthread+0xfd/0x130 [ 1022.724709][ T2556] ? __pfx_kthread+0x10/0x10 [ 1022.725066][ T2556] ret_from_fork+0x2d/0x50 [ 1022.725409][ T2556] ? __pfx_kthread+0x10/0x10 [ 1022.725799][ T2556] ret_from_fork_asm+0x1b/0x30 [ 1022.726201][ T2556] To fix we add an skb_get() before passing the skb to be enqueued in theengress queue. This bumps the skb->users refcnt so that consume_skb()and kfree_skb will not immediately free the sk_buff. With this we canbe sure the skb is still around when we do the dequeue. Then we justneed to decrement the refcnt or free the skb in the backlog case whichwe do by calling kfree_skb() on the ingress case as well as the sendmsgcase.Before locking change from fixes tag we had the sock locked so wecouldn't race with user and there was no issue here.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to do sanity check on direct node in truncate_dnode()syzbot reports below bug:BUG: KASAN: slab-use-after-free in f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574Read of size 4 at addr ffff88802a25c000 by task syz-executor148/5000CPU: 1 PID: 5000 Comm: syz-executor148 Not tainted 6.4.0-rc7-syzkaller-00041-ge660abd551f1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574 truncate_dnode+0x229/0x2e0 fs/f2fs/node.c:944 f2fs_truncate_inode_blocks+0x64b/0xde0 fs/f2fs/node.c:1154 f2fs_do_truncate_blocks+0x4ac/0xf30 fs/f2fs/file.c:721 f2fs_truncate_blocks+0x7b/0x300 fs/f2fs/file.c:749 f2fs_truncate.part.0+0x4a5/0x630 fs/f2fs/file.c:799 f2fs_truncate include/linux/fs.h:825 [inline] f2fs_setattr+0x1738/0x2090 fs/f2fs/file.c:1006 notify_change+0xb2c/0x1180 fs/attr.c:483 do_truncate+0x143/0x200 fs/open.c:66 handle_truncate fs/namei.c:3295 [inline] do_open fs/namei.c:3640 [inline] path_openat+0x2083/0x2750 fs/namei.c:3791 do_filp_open+0x1ba/0x410 fs/namei.c:3818 do_sys_openat2+0x16d/0x4c0 fs/open.c:1356 do_sys_open fs/open.c:1372 [inline] __do_sys_creat fs/open.c:1448 [inline] __se_sys_creat fs/open.c:1442 [inline] __x64_sys_creat+0xcd/0x120 fs/open.c:1442 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe root cause is, inodeA references inodeB via inodeB's ino, once inodeAis truncated, it calls truncate_dnode() to truncate data blocks in inodeB'snode page, it traverse mapping data from node->i.i_addr[0] tonode->i.i_addr[ADDRS_PER_BLOCK() - 1], result in out-of-boundary access.This patch fixes to add sanity check on dnode page in truncate_dnode(),so that, it can help to avoid triggering such issue, and once it encounterssuch issue, it will record newly introduced ERROR_INVALID_NODE_REFERENCEerror into superblock, later fsck can detect such issue and try repairing.Also, it removes f2fs_truncate_data_blocks() for cleanup due to thefunction has only one caller, and uses f2fs_truncate_data_blocks_range()instead.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dp: Drop aux devices together with DP controllerUsing devres to depopulate the aux bus made sure that upon a probedeferral the EDP panel device would be destroyed and recreated upon nextattempt.But the struct device which the devres is tied to is the DPUs(drm_dev->dev), which may be happen after the DP controller is torndown.Indications of this can be seen in the commonly seen EDID-hexdump fullof zeros in the log, or the occasional/rare KASAN fault where thepanel's attempt to read the EDID information causes a use after free onDP resources.It's tempting to move the devres to the DP controller's struct device,but the resources used by the device(s) on the aux bus are explicitlytorn down in the error path. The KASAN-reported use-after-free alsoremains, as the DP aux "module" explicitly frees its devres-allocatedmemory in this code path.As such, explicitly depopulate the aux bus in the error path, and in thecomponent unbind path, to avoid these issues.Patchwork: https://patchwork.freedesktop.org/patch/542163/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: annotate accesses to nlk->cb_runningBoth netlink_recvmsg() and netlink_native_seq_show() readnlk->cb_running locklessly. Use READ_ONCE() there.Add corresponding WRITE_ONCE() to netlink_dump() and__netlink_dump_start()syzbot reported:BUG: KCSAN: data-race in __netlink_dump_start / netlink_recvmsgwrite to 0xffff88813ea4db59 of 1 bytes by task 28219 on cpu 0:__netlink_dump_start+0x3af/0x4d0 net/netlink/af_netlink.c:2399netlink_dump_start include/linux/netlink.h:308 [inline]rtnetlink_rcv_msg+0x70f/0x8c0 net/core/rtnetlink.c:6130netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2577rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6192netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]netlink_unicast+0x56f/0x640 net/netlink/af_netlink.c:1365netlink_sendmsg+0x665/0x770 net/netlink/af_netlink.c:1942sock_sendmsg_nosec net/socket.c:724 [inline]sock_sendmsg net/socket.c:747 [inline]sock_write_iter+0x1aa/0x230 net/socket.c:1138call_write_iter include/linux/fs.h:1851 [inline]new_sync_write fs/read_write.c:491 [inline]vfs_write+0x463/0x760 fs/read_write.c:584ksys_write+0xeb/0x1a0 fs/read_write.c:637__do_sys_write fs/read_write.c:649 [inline]__se_sys_write fs/read_write.c:646 [inline]__x64_sys_write+0x42/0x50 fs/read_write.c:646do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdread to 0xffff88813ea4db59 of 1 bytes by task 28222 on cpu 1:netlink_recvmsg+0x3b4/0x730 net/netlink/af_netlink.c:2022sock_recvmsg_nosec+0x4c/0x80 net/socket.c:1017____sys_recvmsg+0x2db/0x310 net/socket.c:2718___sys_recvmsg net/socket.c:2762 [inline]do_recvmmsg+0x2e5/0x710 net/socket.c:2856__sys_recvmmsg net/socket.c:2935 [inline]__do_sys_recvmmsg net/socket.c:2958 [inline]__se_sys_recvmmsg net/socket.c:2951 [inline]__x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x00 -> 0x01
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: ocelot: call dsa_tag_8021q_unregister() under rtnl_lock() on driver removeWhen the tagging protocol in current use is "ocelot-8021q" and we unbindthe driver, we see this splat:$ echo '0000:00:00.2' > /sys/bus/pci/drivers/fsl_enetc/unbindmscc_felix 0000:00:00.5 swp0: left promiscuous modesja1105 spi2.0: Link is DownDSA: tree 1 torn downmscc_felix 0000:00:00.5 swp2: left promiscuous modesja1105 spi2.2: Link is DownDSA: tree 3 torn downfsl_enetc 0000:00:00.2 eno2: left promiscuous modemscc_felix 0000:00:00.5: Link is Down------------[ cut here ]------------RTNL: assertion failed at net/dsa/tag_8021q.c (409)WARNING: CPU: 1 PID: 329 at net/dsa/tag_8021q.c:409 dsa_tag_8021q_unregister+0x12c/0x1a0Modules linked in:CPU: 1 PID: 329 Comm: bash Not tainted 6.5.0-rc3+ #771pc : dsa_tag_8021q_unregister+0x12c/0x1a0lr : dsa_tag_8021q_unregister+0x12c/0x1a0Call trace: dsa_tag_8021q_unregister+0x12c/0x1a0 felix_tag_8021q_teardown+0x130/0x150 felix_teardown+0x3c/0xd8 dsa_tree_teardown_switches+0xbc/0xe0 dsa_unregister_switch+0x168/0x260 felix_pci_remove+0x30/0x60 pci_device_remove+0x4c/0x100 device_release_driver_internal+0x188/0x288 device_links_unbind_consumers+0xfc/0x138 device_release_driver_internal+0xe0/0x288 device_driver_detach+0x24/0x38 unbind_store+0xd8/0x108 drv_attr_store+0x30/0x50---[ end trace 0000000000000000 ]---------------[ cut here ]------------RTNL: assertion failed at net/8021q/vlan_core.c (376)WARNING: CPU: 1 PID: 329 at net/8021q/vlan_core.c:376 vlan_vid_del+0x1b8/0x1f0CPU: 1 PID: 329 Comm: bash Tainted: G W 6.5.0-rc3+ #771pc : vlan_vid_del+0x1b8/0x1f0lr : vlan_vid_del+0x1b8/0x1f0 dsa_tag_8021q_unregister+0x8c/0x1a0 felix_tag_8021q_teardown+0x130/0x150 felix_teardown+0x3c/0xd8 dsa_tree_teardown_switches+0xbc/0xe0 dsa_unregister_switch+0x168/0x260 felix_pci_remove+0x30/0x60 pci_device_remove+0x4c/0x100 device_release_driver_internal+0x188/0x288 device_links_unbind_consumers+0xfc/0x138 device_release_driver_internal+0xe0/0x288 device_driver_detach+0x24/0x38 unbind_store+0xd8/0x108 drv_attr_store+0x30/0x50DSA: tree 0 torn downThis was somewhat not so easy to spot, because "ocelot-8021q" is not thedefault tagging protocol, and thus, not everyone who tests the unbindingpath may have switched to it beforehand. The defaultfelix_tag_npi_teardown() does not require rtnl_lock() to be held.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:of: overlay: Call of_changeset_init() earlyWhen of_overlay_fdt_apply() fails, the changeset may be partiallyapplied, and the caller is still expected to call of_overlay_remove() toclean up this partial state.However, of_overlay_apply() calls of_resolve_phandles() beforeinit_overlay_changeset(). Hence if the overlay fails to apply due to anunresolved symbol, the overlay_changeset.cset.entries list is stilluninitialized, and cleanup will crash with a NULL-pointer dereference inoverlay_removal_is_ok().Fix this by moving the call to of_changeset_init() frominit_overlay_changeset() to of_overlay_fdt_apply(), where all otherearly initialization is done.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: bpf_sk_storage: Fix invalid wait context lockdep report'./test_progs -t test_local_storage' reported a splat:[ 27.137569] =============================[ 27.138122] [ BUG: Invalid wait context ][ 27.138650] 6.5.0-03980-gd11ae1b16b0a #247 Tainted: G O[ 27.139542] -----------------------------[ 27.140106] test_progs/1729 is trying to lock:[ 27.140713] ffff8883ef047b88 (stock_lock){-.-.}-{3:3}, at: local_lock_acquire+0x9/0x130[ 27.141834] other info that might help us debug this:[ 27.142437] context-{5:5}[ 27.142856] 2 locks held by test_progs/1729:[ 27.143352] #0: ffffffff84bcd9c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x4/0x40[ 27.144492] #1: ffff888107deb2c0 (&storage->lock){..-.}-{2:2}, at: bpf_local_storage_update+0x39e/0x8e0[ 27.145855] stack backtrace:[ 27.146274] CPU: 0 PID: 1729 Comm: test_progs Tainted: G O 6.5.0-03980-gd11ae1b16b0a #247[ 27.147550] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014[ 27.149127] Call Trace:[ 27.149490] [ 27.149867] dump_stack_lvl+0x130/0x1d0[ 27.152609] dump_stack+0x14/0x20[ 27.153131] __lock_acquire+0x1657/0x2220[ 27.153677] lock_acquire+0x1b8/0x510[ 27.157908] local_lock_acquire+0x29/0x130[ 27.159048] obj_cgroup_charge+0xf4/0x3c0[ 27.160794] slab_pre_alloc_hook+0x28e/0x2b0[ 27.161931] __kmem_cache_alloc_node+0x51/0x210[ 27.163557] __kmalloc+0xaa/0x210[ 27.164593] bpf_map_kzalloc+0xbc/0x170[ 27.165147] bpf_selem_alloc+0x130/0x510[ 27.166295] bpf_local_storage_update+0x5aa/0x8e0[ 27.167042] bpf_fd_sk_storage_update_elem+0xdb/0x1a0[ 27.169199] bpf_map_update_value+0x415/0x4f0[ 27.169871] map_update_elem+0x413/0x550[ 27.170330] __sys_bpf+0x5e9/0x640[ 27.174065] __x64_sys_bpf+0x80/0x90[ 27.174568] do_syscall_64+0x48/0xa0[ 27.175201] entry_SYSCALL_64_after_hwframe+0x6e/0xd8[ 27.175932] RIP: 0033:0x7effb40e41ad[ 27.176357] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d8[ 27.179028] RSP: 002b:00007ffe64c21fc8 EFLAGS: 00000202 ORIG_RAX: 0000000000000141[ 27.180088] RAX: ffffffffffffffda RBX: 00007ffe64c22768 RCX: 00007effb40e41ad[ 27.181082] RDX: 0000000000000020 RSI: 00007ffe64c22008 RDI: 0000000000000002[ 27.182030] RBP: 00007ffe64c21ff0 R08: 0000000000000000 R09: 00007ffe64c22788[ 27.183038] R10: 0000000000000064 R11: 0000000000000202 R12: 0000000000000000[ 27.184006] R13: 00007ffe64c22788 R14: 00007effb42a1000 R15: 0000000000000000[ 27.184958] It complains about acquiring a local_lock while holding a raw_spin_lock.It means it should not allocate memory while holding a raw_spin_locksince it is not safe for RT.raw_spin_lock is needed because bpf_local_storage supports tracingcontext. In particular for task local storage, it is easy toget a "current" task PTR_TO_BTF_ID in tracing bpf prog.However, task (and cgroup) local storage has already been moved tobpf mem allocator which can be used after raw_spin_lock.The splat is for the sk storage. For sk (and inode) storage,it has not been moved to bpf mem allocator. Using raw_spin_lock or not,kzalloc(GFP_ATOMIC) could theoretically be unsafe in tracing context.However, the local storage helper requires a verifier acceptedsk pointer (PTR_TO_BTF_ID), it is hypothetical if that (mean runninga bpf prog in a kzalloc unsafe context and also able to hold a verifieraccepted sk pointer) could happen.This patch avoids kzalloc after raw_spin_lock to silent the splat.There is an existing kzalloc before the raw_spin_lock. At that point,a kzalloc is very likely required because a lookup has just been donebefore. Thus, this patch always does the kzalloc before acq---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: do not hard code device address lenth in fdb dumpssyzbot reports that some netdev devices do not have a six bytesaddress [1]Replace ETH_ALEN by dev->addr_len.[1] (Case of a device where dev->addr_len = 4)BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]BUG: KMSAN: kernel-infoleak in copyout+0xb8/0x100 lib/iov_iter.c:169instrument_copy_to_user include/linux/instrumented.h:114 [inline]copyout+0xb8/0x100 lib/iov_iter.c:169_copy_to_iter+0x6d8/0x1d00 lib/iov_iter.c:536copy_to_iter include/linux/uio.h:206 [inline]simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:513__skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:527skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]netlink_recvmsg+0x4ae/0x15a0 net/netlink/af_netlink.c:1970sock_recvmsg_nosec net/socket.c:1019 [inline]sock_recvmsg net/socket.c:1040 [inline]____sys_recvmsg+0x283/0x7f0 net/socket.c:2722___sys_recvmsg+0x223/0x840 net/socket.c:2764do_recvmmsg+0x4f9/0xfd0 net/socket.c:2858__sys_recvmmsg net/socket.c:2937 [inline]__do_sys_recvmmsg net/socket.c:2960 [inline]__se_sys_recvmmsg net/socket.c:2953 [inline]__x64_sys_recvmmsg+0x397/0x490 net/socket.c:2953do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was stored to memory at:__nla_put lib/nlattr.c:1009 [inline]nla_put+0x1c6/0x230 lib/nlattr.c:1067nlmsg_populate_fdb_fill+0x2b8/0x600 net/core/rtnetlink.c:4071nlmsg_populate_fdb net/core/rtnetlink.c:4418 [inline]ndo_dflt_fdb_dump+0x616/0x840 net/core/rtnetlink.c:4456rtnl_fdb_dump+0x14ff/0x1fc0 net/core/rtnetlink.c:4629netlink_dump+0x9d1/0x1310 net/netlink/af_netlink.c:2268netlink_recvmsg+0xc5c/0x15a0 net/netlink/af_netlink.c:1995sock_recvmsg_nosec+0x7a/0x120 net/socket.c:1019____sys_recvmsg+0x664/0x7f0 net/socket.c:2720___sys_recvmsg+0x223/0x840 net/socket.c:2764do_recvmmsg+0x4f9/0xfd0 net/socket.c:2858__sys_recvmmsg net/socket.c:2937 [inline]__do_sys_recvmmsg net/socket.c:2960 [inline]__se_sys_recvmmsg net/socket.c:2953 [inline]__x64_sys_recvmmsg+0x397/0x490 net/socket.c:2953do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at:slab_post_alloc_hook+0x12d/0xb60 mm/slab.h:716slab_alloc_node mm/slub.c:3451 [inline]__kmem_cache_alloc_node+0x4ff/0x8b0 mm/slub.c:3490kmalloc_trace+0x51/0x200 mm/slab_common.c:1057kmalloc include/linux/slab.h:559 [inline]__hw_addr_create net/core/dev_addr_lists.c:60 [inline]__hw_addr_add_ex+0x2e5/0x9e0 net/core/dev_addr_lists.c:118__dev_mc_add net/core/dev_addr_lists.c:867 [inline]dev_mc_add+0x9a/0x130 net/core/dev_addr_lists.c:885igmp6_group_added+0x267/0xbc0 net/ipv6/mcast.c:680ipv6_mc_up+0x296/0x3b0 net/ipv6/mcast.c:2754ipv6_mc_remap+0x1e/0x30 net/ipv6/mcast.c:2708addrconf_type_change net/ipv6/addrconf.c:3731 [inline]addrconf_notify+0x4d3/0x1d90 net/ipv6/addrconf.c:3699notifier_call_chain kernel/notifier.c:93 [inline]raw_notifier_call_chain+0xe4/0x430 kernel/notifier.c:461call_netdevice_notifiers_info net/core/dev.c:1935 [inline]call_netdevice_notifiers_extack net/core/dev.c:1973 [inline]call_netdevice_notifiers+0x1ee/0x2d0 net/core/dev.c:1987bond_enslave+0xccd/0x53f0 drivers/net/bonding/bond_main.c:1906do_set_master net/core/rtnetlink.c:2626 [inline]rtnl_newlink_create net/core/rtnetlink.c:3460 [inline]__rtnl_newlink net/core/rtnetlink.c:3660 [inline]rtnl_newlink+0x378c/0x40e0 net/core/rtnetlink.c:3673rtnetlink_rcv_msg+0x16a6/0x1840 net/core/rtnetlink.c:6395netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2546rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6413netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]netlink_unicast+0xf28/0x1230 net/netlink/af_---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix warning when putting transaction with qgroups enabled after abortIf we have a transaction abort with qgroups enabled we get a warningtriggered when doing the final put on the transaction, like this: [552.6789] ------------[ cut here ]------------ [552.6815] WARNING: CPU: 4 PID: 81745 at fs/btrfs/transaction.c:144 btrfs_put_transaction+0x123/0x130 [btrfs] [552.6817] Modules linked in: btrfs blake2b_generic xor (...) [552.6819] CPU: 4 PID: 81745 Comm: btrfs-transacti Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1 [552.6819] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [552.6819] RIP: 0010:btrfs_put_transaction+0x123/0x130 [btrfs] [552.6821] Code: bd a0 01 00 (...) [552.6821] RSP: 0018:ffffa168c0527e28 EFLAGS: 00010286 [552.6821] RAX: ffff936042caed00 RBX: ffff93604a3eb448 RCX: 0000000000000000 [552.6821] RDX: ffff93606421b028 RSI: ffffffff92ff0878 RDI: ffff93606421b010 [552.6821] RBP: ffff93606421b000 R08: 0000000000000000 R09: ffffa168c0d07c20 [552.6821] R10: 0000000000000000 R11: ffff93608dc52950 R12: ffffa168c0527e70 [552.6821] R13: ffff93606421b000 R14: ffff93604a3eb420 R15: ffff93606421b028 [552.6821] FS: 0000000000000000(0000) GS:ffff93675fb00000(0000) knlGS:0000000000000000 [552.6821] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [552.6821] CR2: 0000558ad262b000 CR3: 000000014feda005 CR4: 0000000000370ee0 [552.6822] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [552.6822] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [552.6822] Call Trace: [552.6822] [552.6822] ? __warn+0x80/0x130 [552.6822] ? btrfs_put_transaction+0x123/0x130 [btrfs] [552.6824] ? report_bug+0x1f4/0x200 [552.6824] ? handle_bug+0x42/0x70 [552.6824] ? exc_invalid_op+0x14/0x70 [552.6824] ? asm_exc_invalid_op+0x16/0x20 [552.6824] ? btrfs_put_transaction+0x123/0x130 [btrfs] [552.6826] btrfs_cleanup_transaction+0xe7/0x5e0 [btrfs] [552.6828] ? _raw_spin_unlock_irqrestore+0x23/0x40 [552.6828] ? try_to_wake_up+0x94/0x5e0 [552.6828] ? __pfx_process_timeout+0x10/0x10 [552.6828] transaction_kthread+0x103/0x1d0 [btrfs] [552.6830] ? __pfx_transaction_kthread+0x10/0x10 [btrfs] [552.6832] kthread+0xee/0x120 [552.6832] ? __pfx_kthread+0x10/0x10 [552.6832] ret_from_fork+0x29/0x50 [552.6832] [552.6832] ---[ end trace 0000000000000000 ]---This corresponds to this line of code: void btrfs_put_transaction(struct btrfs_transaction *transaction) { (...) WARN_ON(!RB_EMPTY_ROOT( &transaction->delayed_refs.dirty_extent_root)); (...) }The warning happens because btrfs_qgroup_destroy_extent_records(), calledin the transaction abort path, we free all entries from the rbtree"dirty_extent_root" with rbtree_postorder_for_each_entry_safe(), but wedon't actually empty the rbtree - it's still pointing to nodes that werefreed.So set the rbtree's root node to NULL to avoid this warning (assignRB_ROOT).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix potential use-after-free bug when trimming capsWhen trimming the caps and just after the 'session->s_cap_lock' isreleased in ceph_iterate_session_caps() the cap maybe removed byanother thread, and when using the stale cap memory in the callbacksit will trigger use-after-free crash.We need to check the existence of the cap just after the 'ci->i_ceph_lock'being acquired. And do nothing if it's already removed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mips: bmips: BCM6358: disable RAC flush for TP1RAC flush causes kernel panics on BCM6358 with EHCI/OHCI when booting from TP1:[ 3.881739] usb 1-1: new high-speed USB device number 2 using ehci-platform[ 3.895011] Reserved instruction in kernel code[#1]:[ 3.900113] CPU: 0 PID: 1 Comm: init Not tainted 5.10.16 #0[ 3.905829] $ 0 : 00000000 10008700 00000000 77d94060[ 3.911238] $ 4 : 7fd1f088 00000000 81431cac 81431ca0[ 3.916641] $ 8 : 00000000 ffffefff 8075cd34 00000000[ 3.922043] $12 : 806f8d40 f3e812b7 00000000 000d9aaa[ 3.927446] $16 : 7fd1f068 7fd1f080 7ff559b8 81428470[ 3.932848] $20 : 00000000 00000000 55590000 77d70000[ 3.938251] $24 : 00000018 00000010[ 3.943655] $28 : 81430000 81431e60 81431f28 800157fc[ 3.949058] Hi : 00000000[ 3.952013] Lo : 00000000[ 3.955019] epc : 80015808 setup_sigcontext+0x54/0x24c[ 3.960464] ra : 800157fc setup_sigcontext+0x48/0x24c[ 3.965913] Status: 10008703 KERNEL EXL IE[ 3.970216] Cause : 00800028 (ExcCode 0a)[ 3.974340] PrId : 0002a010 (Broadcom BMIPS4350)[ 3.979170] Modules linked in: ohci_platform ohci_hcd fsl_mph_dr_of ehci_platform ehci_fsl ehci_hcd gpio_button_hotplug usbcore nls_base usb_common[ 3.992907] Process init (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=77e22ec8)[ 4.000776] Stack : 81431ef4 7fd1f080 81431f28 81428470 7fd1f068 81431edc 7ff559b8 81428470[ 4.009467] 81431f28 7fd1f080 55590000 77d70000 77d5498c 80015c70 806f0000 8063ae74[ 4.018149] 08100002 81431f28 0000000a 08100002 81431f28 0000000a 77d6b418 00000003[ 4.026831] ffffffff 80016414 80080734 81431ecc 81431ecc 00000001 00000000 04000000[ 4.035512] 77d54874 00000000 00000000 00000000 00000000 00000012 00000002 00000000[ 4.044196] ...[ 4.046706] Call Trace:[ 4.049238] [<80015808>] setup_sigcontext+0x54/0x24c[ 4.054356] [<80015c70>] setup_frame+0xdc/0x124[ 4.059015] [<80016414>] do_notify_resume+0x1dc/0x288[ 4.064207] [<80011b50>] work_notifysig+0x10/0x18[ 4.069036][ 4.070538] Code: 8fc300b4 00001025 26240008
ac830004 3c048063 0c0228aa 24846a00 26240010[ 4.080686][ 4.082517] ---[ end trace 22a8edb41f5f983b ]---[ 4.087374] Kernel panic - not syncing: Fatal exception[ 4.092753] Rebooting in 1 seconds..Because the bootloader (CFE) is not initializing the Read-ahead cache properlyon the second thread (TP1). Since the RAC was not initialized properly, weshould avoid flushing it at the risk of corrupting the instruction stream asseen in the trace above.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: ocb: don't leave if not joinedIf there's no OCB state, don't ask the driver/mac80211 toleave, since that's just confusing. Since set/clear thechandef state, that's a simple check.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ionic: remove WARN_ON to prevent panic_on_warnRemove unnecessary early code development check and the WARN_ONthat it uses. The irq alloc and free paths have long beencleaned up and this check shouldn't have stuck around so long.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: TC, Fix internal port memory leakThe flow rule can be splited, and the extra post_act rules are addedto post_act table. It's possible to trigger memleak when the ruleforwards packets from internal port and over tunnel, in the case that,for example, CT 'new' state offload is allowed. As int_port object isassigned to the flow attribute of post_act rule, and its refcnt isincremented by mlx5e_tc_int_port_get(), but mlx5e_tc_int_port_put() isnot called, the refcnt is never decremented, then int_port is neverfreed.The kmemleak reports the following error:unreferenced object 0xffff888128204b80 (size 64): comm "handler20", pid 50121, jiffies 4296973009 (age 642.932s) hex dump (first 32 bytes): 01 00 00 00 19 00 00 00 03 f0 00 00 04 00 00 00 ................ 98 77 67 41 81 88 ff ff 98 77 67 41 81 88 ff ff .wgA.....wgA.... backtrace: [<00000000e992680d>] kmalloc_trace+0x27/0x120 [<000000009e945a98>] mlx5e_tc_int_port_get+0x3f3/0xe20 [mlx5_core] [<0000000035a537f0>] mlx5e_tc_add_fdb_flow+0x473/0xcf0 [mlx5_core] [<0000000070c2cec6>] __mlx5e_add_fdb_flow+0x7cf/0xe90 [mlx5_core] [<000000005cc84048>] mlx5e_configure_flower+0xd40/0x4c40 [mlx5_core] [<000000004f8a2031>] mlx5e_rep_indr_offload.isra.0+0x10e/0x1c0 [mlx5_core] [<000000007df797dc>] mlx5e_rep_indr_setup_tc_cb+0x90/0x130 [mlx5_core] [<0000000016c15cc3>] tc_setup_cb_add+0x1cf/0x410 [<00000000a63305b4>] fl_hw_replace_filter+0x38f/0x670 [cls_flower] [<000000008bc9e77c>] fl_change+0x1fd5/0x4430 [cls_flower] [<00000000e7f766e4>] tc_new_tfilter+0x867/0x2010 [<00000000e101c0ef>] rtnetlink_rcv_msg+0x6fc/0x9f0 [<00000000e1111d44>] netlink_rcv_skb+0x12c/0x360 [<0000000082dd6c8b>] netlink_unicast+0x438/0x710 [<00000000fc568f70>] netlink_sendmsg+0x794/0xc50 [<0000000016e92590>] sock_sendmsg+0xc5/0x190So fix this by moving int_port cleanup code to the flow attributefree helper, which is used by all the attribute free cases.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated().syzbot reported [0] a null-ptr-deref in sk_get_rmem0() while usingIPPROTO_UDPLITE (0x88): 14:25:52 executing program 1: r0 = socket$inet6(0xa, 0x80002, 0x88)We had a similar report [1] for probably sk_memory_allocated_add()in __sk_mem_raise_allocated(), and commit c915fe13cbaa ("udplite: fixNULL pointer dereference") fixed it by setting .memory_allocated forudplite_prot and udplitev6_prot.To fix the variant, we need to set either .sysctl_wmem_offset or.sysctl_rmem.Now UDP and UDPLITE share the same value for .memory_allocated, so weuse the same .sysctl_wmem_offset for UDP and UDPLITE.[0]:general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 0 PID: 6829 Comm: syz-executor.1 Not tainted 6.4.0-rc2-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023RIP: 0010:sk_get_rmem0 include/net/sock.h:2907 [inline]RIP: 0010:__sk_mem_raise_allocated+0x806/0x17a0 net/core/sock.c:3006Code: c1 ea 03 80 3c 02 00 0f 85 23 0f 00 00 48 8b 44 24 08 48 8b 98 38 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <0f> b6 14 02 48 89 d8 83 e0 07 83 c0 03 38 d0 0f 8d 6f 0a 00 00 8bRSP: 0018:ffffc90005d7f450 EFLAGS: 00010246RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004d92000RDX: 0000000000000000 RSI: ffffffff88066482 RDI: ffffffff8e2ccbb8RBP: ffff8880173f7000 R08: 0000000000000005 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000030000R13: 0000000000000001 R14: 0000000000000340 R15: 0000000000000001FS: 0000000000000000(0000) GS:ffff8880b9800000(0063) knlGS:00000000f7f1cb40CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033CR2: 000000002e82f000 CR3: 0000000034ff0000 CR4: 00000000003506f0Call Trace: __sk_mem_schedule+0x6c/0xe0 net/core/sock.c:3077 udp_rmem_schedule net/ipv4/udp.c:1539 [inline] __udp_enqueue_schedule_skb+0x776/0xb30 net/ipv4/udp.c:1581 __udpv6_queue_rcv_skb net/ipv6/udp.c:666 [inline] udpv6_queue_rcv_one_skb+0xc39/0x16c0 net/ipv6/udp.c:775 udpv6_queue_rcv_skb+0x194/0xa10 net/ipv6/udp.c:793 __udp6_lib_mcast_deliver net/ipv6/udp.c:906 [inline] __udp6_lib_rcv+0x1bda/0x2bd0 net/ipv6/udp.c:1013 ip6_protocol_deliver_rcu+0x2e7/0x1250 net/ipv6/ip6_input.c:437 ip6_input_finish+0x150/0x2f0 net/ipv6/ip6_input.c:482 NF_HOOK include/linux/netfilter.h:303 [inline] NF_HOOK include/linux/netfilter.h:297 [inline] ip6_input+0xa0/0xd0 net/ipv6/ip6_input.c:491 ip6_mc_input+0x40b/0xf50 net/ipv6/ip6_input.c:585 dst_input include/net/dst.h:468 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] NF_HOOK include/linux/netfilter.h:303 [inline] NF_HOOK include/linux/netfilter.h:297 [inline] ipv6_rcv+0x250/0x380 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5491 __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5605 netif_receive_skb_internal net/core/dev.c:5691 [inline] netif_receive_skb+0x133/0x7a0 net/core/dev.c:5750 tun_rx_batched+0x4b3/0x7a0 drivers/net/tun.c:1553 tun_get_user+0x2452/0x39c0 drivers/net/tun.c:1989 tun_chr_write_iter+0xdf/0x200 drivers/net/tun.c:2035 call_write_iter include/linux/fs.h:1868 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x945/0xd50 fs/read_write.c:584 ksys_write+0x12b/0x250 fs/read_write.c:637 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82RIP: 0023:0xf7f21579Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:binder: fix memory leak in binder_init()In binder_init(), the destruction of binder_alloc_shrinker_init() is notperformed in the wrong path, which will cause memory leaks. So this commitintroduces binder_alloc_shrinker_exit() and calls it in the wrong path tofix that.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix stack overflow when LRO is disabled for virtual interfacesWhen the virtual interface's feature is updated, it synchronizes theupdated feature for its own lower interface.This propagation logic should be worked as the iteration, not recursively.But it works recursively due to the netdev notification unexpectedly.This problem occurs when it disables LRO only for the team and bondinginterface type. team0 | +------+------+-----+-----+ | | | | |team1 team2 team3 ... team200If team0's LRO feature is updated, it generates the NETDEV_FEAT_CHANGEevent to its own lower interfaces(team1 ~ team200).It is worked by netdev_sync_lower_features().So, the NETDEV_FEAT_CHANGE notification logic of each lower interfacework iteratively.But generated NETDEV_FEAT_CHANGE event is also sent to the upperinterface too.upper interface(team0) generates the NETDEV_FEAT_CHANGE event for its ownlower interfaces again.lower and upper interfaces receive this event and generate thisevent again and again.So, the stack overflow occurs.But it is not the infinite loop issue.Because the netdev_sync_lower_features() updates features beforegenerating the NETDEV_FEAT_CHANGE event.Already synchronized lower interfaces skip notification logic.So, it is just the problem that iteration logic is changed to therecursive unexpectedly due to the notification mechanism.Reproducer:ip link add team0 type teamethtool -K team0 lro onfor i in {1..200}do ip link add team$i master team0 type team ethtool -K team$i lro ondoneethtool -K team0 lro offIn order to fix it, the notifier_ctx member of bonding/team is introduced.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race between balance and cancel/pauseSyzbot reported a panic that looks like this: assertion failed: fs_info->exclusive_operation == BTRFS_EXCLOP_BALANCE_PAUSED, in fs/btrfs/ioctl.c:465 ------------[ cut here ]------------ kernel BUG at fs/btrfs/messages.c:259! RIP: 0010:btrfs_assertfail+0x2c/0x30 fs/btrfs/messages.c:259 Call Trace: btrfs_exclop_balance fs/btrfs/ioctl.c:465 [inline] btrfs_ioctl_balance fs/btrfs/ioctl.c:3564 [inline] btrfs_ioctl+0x531e/0x5b30 fs/btrfs/ioctl.c:4632 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe reproducer is running a balance and a cancel or pause in parallel.The way balance finishes is a bit wonky, if we were paused we need tosave the balance_ctl in the fs_info, but clear it otherwise and cleanup.However we rely on the return values being specific errors, or having acancel request or no pause request. If balance completes and returns 0,but we have a pause or cancel request we won't do the appropriatecleanup, and then the next time we try to start a balance we'll tripthis ASSERT.The error handling is just wrong here, we always want to clean up,unless we got -ECANCELLED and we set the appropriate pause flag in theexclusive op. With this patch the reproducer ran for an hour withouttripping, previously it would trip in less than a few minutes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vdpa: Add queue index attr to vdpa_nl_policy for nlattr length checkThe vdpa_nl_policy structure is used to validate the nlattr when parsingthe incoming nlmsg. It will ensure the attribute being described producesa valid nlattr pointer in info->attrs before entering into each handlerin vdpa_nl_ops.That is to say, the missing part in vdpa_nl_policy may lead to illegalnlattr after parsing, which could lead to OOB read just like CVE-2023-3773.This patch adds the missing nla_policy for vdpa queue index attr to avoidsuch bugs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race when deleting quota root from the dirty cow roots listWhen disabling quotas we are deleting the quota root from the listfs_info->dirty_cowonly_roots without taking the lock that protects it,which is struct btrfs_fs_info::trans_lock. This unsynchronized listmanipulation may cause chaos if there's another concurrent manipulationof this list, such as when adding a root to it withctree.c:add_root_to_dirty_list().This can result in all sorts of weird failures caused by a race, such asthe following crash: [337571.278245] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] PREEMPT SMP PTI [337571.278933] CPU: 1 PID: 115447 Comm: btrfs Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1 [337571.279153] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [337571.279572] RIP: 0010:commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.279928] Code: 85 38 06 00 (...) [337571.280363] RSP: 0018:ffff9f63446efba0 EFLAGS: 00010206 [337571.280582] RAX: ffff942d98ec2638 RBX: ffff9430b82b4c30 RCX: 0000000449e1c000 [337571.280798] RDX: dead000000000100 RSI: ffff9430021e4900 RDI: 0000000000036070 [337571.281015] RBP: ffff942d98ec2000 R08: ffff942d98ec2000 R09: 000000000000015b [337571.281254] R10: 0000000000000009 R11: 0000000000000001 R12: ffff942fe8fbf600 [337571.281476] R13: ffff942dabe23040 R14: ffff942dabe20800 R15: ffff942d92cf3b48 [337571.281723] FS: 00007f478adb7340(0000) GS:ffff94349fa40000(0000) knlGS:0000000000000000 [337571.281950] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [337571.282184] CR2: 00007f478ab9a3d5 CR3: 000000001e02c001 CR4: 0000000000370ee0 [337571.282416] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [337571.282647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [337571.282874] Call Trace: [337571.283101] [337571.283327] ? __die_body+0x1b/0x60 [337571.283570] ? die_addr+0x39/0x60 [337571.283796] ? exc_general_protection+0x22e/0x430 [337571.284022] ? asm_exc_general_protection+0x22/0x30 [337571.284251] ? commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.284531] btrfs_commit_transaction+0x42e/0xf90 [btrfs] [337571.284803] ? _raw_spin_unlock+0x15/0x30 [337571.285031] ? release_extent_buffer+0x103/0x130 [btrfs] [337571.285305] reset_balance_state+0x152/0x1b0 [btrfs] [337571.285578] btrfs_balance+0xa50/0x11e0 [btrfs] [337571.285864] ? __kmem_cache_alloc_node+0x14a/0x410 [337571.286086] btrfs_ioctl+0x249a/0x3320 [btrfs] [337571.286358] ? mod_objcg_state+0xd2/0x360 [337571.286577] ? refill_obj_stock+0xb0/0x160 [337571.286798] ? seq_release+0x25/0x30 [337571.287016] ? __rseq_handle_notify_resume+0x3ba/0x4b0 [337571.287235] ? percpu_counter_add_batch+0x2e/0xa0 [337571.287455] ? __x64_sys_ioctl+0x88/0xc0 [337571.287675] __x64_sys_ioctl+0x88/0xc0 [337571.287901] do_syscall_64+0x38/0x90 [337571.288126] entry_SYSCALL_64_after_hwframe+0x72/0xdc [337571.288352] RIP: 0033:0x7f478aaffe9bSo fix this by locking struct btrfs_fs_info::trans_lock before deletingthe quota root from that list.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix a memory leak in the LRU and LRU_PERCPU hash mapsThe LRU and LRU_PERCPU maps allocate a new element on update before locking thetarget hash table bucket. Right after that the maps try to lock the bucket.If this fails, then maps return -EBUSY to the caller without releasing theallocated element. This makes the element untracked: it doesn't belong toeither of free lists, and it doesn't belong to the hash table, so can't bere-used; this eventually leads to the permanent -ENOMEM on LRU map updates,which is unexpected. Fix this by returning the element to the local free listif bucket locking fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: mt7921: fix skb leak by txs missing in AMSDUtxs may be dropped if the frame is aggregated in AMSDU. When the problemshows up, some SKBs would be hold in driver to cause network stoppedtemporarily. Even if the problem can be recovered by txs timeout handling,mt7921 still need to disable txs in AMSDU to avoid this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kheaders: Use array declaration instead of charUnder CONFIG_FORTIFY_SOURCE, memcpy() will check the size of destinationand source buffers. Defining kernel_headers_data as "char" would tripthis check. Since these addresses are treated as byte arrays, definethem as arrays (as done everywhere else).This was seen with: $ cat /sys/kernel/kheaders.tar.xz >> /dev/null detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1027! ... RIP: 0010:fortify_panic+0xf/0x20 [...] Call Trace: ikheaders_read+0x45/0x50 [kheaders] kernfs_fop_read_iter+0x1a4/0x2f0 ...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb-v2: gl861: Fix null-ptr-deref in gl861_i2c_master_xferIn gl861_i2c_master_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach gl861_i2c_master_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race when deleting free space root from the dirty cow roots listWhen deleting the free space tree we are deleting the free space rootfrom the list fs_info->dirty_cowonly_roots without taking the lock thatprotects it, which is struct btrfs_fs_info::trans_lock.This unsynchronized list manipulation may cause chaos if there's anotherconcurrent manipulation of this list, such as when adding a root to itwith ctree.c:add_root_to_dirty_list().This can result in all sorts of weird failures caused by a race, such asthe following crash: [337571.278245] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] PREEMPT SMP PTI [337571.278933] CPU: 1 PID: 115447 Comm: btrfs Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1 [337571.279153] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [337571.279572] RIP: 0010:commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.279928] Code: 85 38 06 00 (...) [337571.280363] RSP: 0018:ffff9f63446efba0 EFLAGS: 00010206 [337571.280582] RAX: ffff942d98ec2638 RBX: ffff9430b82b4c30 RCX: 0000000449e1c000 [337571.280798] RDX: dead000000000100 RSI: ffff9430021e4900 RDI: 0000000000036070 [337571.281015] RBP: ffff942d98ec2000 R08: ffff942d98ec2000 R09: 000000000000015b [337571.281254] R10: 0000000000000009 R11: 0000000000000001 R12: ffff942fe8fbf600 [337571.281476] R13: ffff942dabe23040 R14: ffff942dabe20800 R15: ffff942d92cf3b48 [337571.281723] FS: 00007f478adb7340(0000) GS:ffff94349fa40000(0000) knlGS:0000000000000000 [337571.281950] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [337571.282184] CR2: 00007f478ab9a3d5 CR3: 000000001e02c001 CR4: 0000000000370ee0 [337571.282416] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [337571.282647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [337571.282874] Call Trace: [337571.283101] [337571.283327] ? __die_body+0x1b/0x60 [337571.283570] ? die_addr+0x39/0x60 [337571.283796] ? exc_general_protection+0x22e/0x430 [337571.284022] ? asm_exc_general_protection+0x22/0x30 [337571.284251] ? commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.284531] btrfs_commit_transaction+0x42e/0xf90 [btrfs] [337571.284803] ? _raw_spin_unlock+0x15/0x30 [337571.285031] ? release_extent_buffer+0x103/0x130 [btrfs] [337571.285305] reset_balance_state+0x152/0x1b0 [btrfs] [337571.285578] btrfs_balance+0xa50/0x11e0 [btrfs] [337571.285864] ? __kmem_cache_alloc_node+0x14a/0x410 [337571.286086] btrfs_ioctl+0x249a/0x3320 [btrfs] [337571.286358] ? mod_objcg_state+0xd2/0x360 [337571.286577] ? refill_obj_stock+0xb0/0x160 [337571.286798] ? seq_release+0x25/0x30 [337571.287016] ? __rseq_handle_notify_resume+0x3ba/0x4b0 [337571.287235] ? percpu_counter_add_batch+0x2e/0xa0 [337571.287455] ? __x64_sys_ioctl+0x88/0xc0 [337571.287675] __x64_sys_ioctl+0x88/0xc0 [337571.287901] do_syscall_64+0x38/0x90 [337571.288126] entry_SYSCALL_64_after_hwframe+0x72/0xdc [337571.288352] RIP: 0033:0x7f478aaffe9bSo fix this by locking struct btrfs_fs_info::trans_lock before deletingthe free space root from that list.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen: speed up grant-table reclaimWhen a grant entry is still in use by the remote domain, Linux must putit on a deferred list. Normally, this list is very short, becausethe PV network and block protocols expect the backend to unmap the grantfirst. However, Qubes OS's GUI protocol is subject to the constraintsof the X Window System, and as such winds up with the frontend unmappingthe window first. As a result, the list can grow very large, resultingin a massive memory leak and eventual VM freeze.To partially solve this problem, make the number of entries that the VMwill attempt to free at each iteration tunable. The default is still10, but it can be overridden via a module parameter.This is Cc: stable because (when combined with appropriate userspacechanges) it fixes a severe performance and stability problem for QubesOS users.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Add preempt_count_{sub,add} into btf id deny listThe recursion check in __bpf_prog_enter* and __bpf_prog_exit*leave preempt_count_{sub,add} unprotected. When attaching trampoline tothem we get panic as follows,[ 867.843050] BUG: TASK stack guard page was hit at 0000000009d325cf (stack is 0000000046a46a15..00000000537e7b28)[ 867.843064] stack guard page: 0000 [#1] PREEMPT SMP NOPTI[ 867.843067] CPU: 8 PID: 11009 Comm: trace Kdump: loaded Not tainted 6.2.0+ #4[ 867.843100] Call Trace:[ 867.843101] [ 867.843104] asm_exc_int3+0x3a/0x40[ 867.843108] RIP: 0010:preempt_count_sub+0x1/0xa0[ 867.843135] __bpf_prog_enter_recur+0x17/0x90[ 867.843148] bpf_trampoline_6442468108_0+0x2e/0x1000[ 867.843154] ? preempt_count_sub+0x1/0xa0[ 867.843157] preempt_count_sub+0x5/0xa0[ 867.843159] ? migrate_enable+0xac/0xf0[ 867.843164] __bpf_prog_exit_recur+0x2d/0x40[ 867.843168] bpf_trampoline_6442468108_0+0x55/0x1000...[ 867.843788] preempt_count_sub+0x5/0xa0[ 867.843793] ? migrate_enable+0xac/0xf0[ 867.843829] __bpf_prog_exit_recur+0x2d/0x40[ 867.843837] BUG: IRQ stack guard page was hit at 0000000099bd8228 (stack is 00000000b23e2bc4..000000006d95af35)[ 867.843841] BUG: IRQ stack guard page was hit at 000000005ae07924 (stack is 00000000ffd69623..0000000014eb594c)[ 867.843843] BUG: IRQ stack guard page was hit at 00000000028320f0 (stack is 00000000034b6438..0000000078d1bcec)[ 867.843842] bpf_trampoline_6442468108_0+0x55/0x1000...That is because in __bpf_prog_exit_recur, the preempt_count_{sub,add} arecalled after prog->active is decreased.Fixing this by adding these two functions into btf ids deny list.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubi: Fix possible null-ptr-deref in ubi_free_volume()It willl cause null-ptr-deref in the following case:uif_init() ubi_add_volume() cdev_add() -> if it fails, call kill_volumes() device_register()kill_volumes() -> if ubi_add_volume() fails call this function ubi_free_volume() cdev_del() device_unregister() -> trying to delete a not added device, it causes null-ptr-derefSo in ubi_free_volume(), it delete devices whether they are addedor not, it will causes null-ptr-deref.Handle the error case whlie calling ubi_add_volume() to fix thisproblem. If add volume fails, set the corresponding vol to null,so it can not be accessed in kill_volumes() and release theresource in ubi_add_volume() error path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: anysee: fix null-ptr-deref in anysee_master_xferIn anysee_master_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach anysee_master_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")[hverkuil: add spaces around +]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: prevent skb corruption on frag list segmentationIan reported several skb corruptions triggered by rx-gro-list,collecting different oops alike:[ 62.624003] BUG: kernel NULL pointer dereference, address: 00000000000000c0[ 62.631083] #PF: supervisor read access in kernel mode[ 62.636312] #PF: error_code(0x0000) - not-present page[ 62.641541] PGD 0 P4D 0[ 62.644174] Oops: 0000 [#1] PREEMPT SMP NOPTI[ 62.648629] CPU: 1 PID: 913 Comm: napi/eno2-79 Not tainted 6.4.0 #364[ 62.655162] Hardware name: Supermicro Super Server/A2SDi-12C-HLN4F, BIOS 1.7a 10/13/2022[ 62.663344] RIP: 0010:__udp_gso_segment (./include/linux/skbuff.h:2858./include/linux/udp.h:23 net/ipv4/udp_offload.c:228 net/ipv4/udp_offload.c:261net/ipv4/udp_offload.c:277)[ 62.687193] RSP: 0018:ffffbd3a83b4f868 EFLAGS: 00010246[ 62.692515] RAX: 00000000000000ce RBX: 0000000000000000 RCX: 0000000000000000[ 62.699743] RDX: ffffa124def8a000 RSI: 0000000000000079 RDI: ffffa125952a14d4[ 62.706970] RBP: ffffa124def8a000 R08: 0000000000000022 R09: 00002000001558c9[ 62.714199] R10: 0000000000000000 R11: 00000000be554639 R12: 00000000000000e2[ 62.721426] R13: ffffa125952a1400 R14: ffffa125952a1400 R15: 00002000001558c9[ 62.728654] FS: 0000000000000000(0000) GS:ffffa127efa40000(0000)knlGS:0000000000000000[ 62.736852] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 62.742702] CR2: 00000000000000c0 CR3: 00000001034b0000 CR4: 00000000003526e0[ 62.749948] Call Trace:[ 62.752498] [ 62.779267] inet_gso_segment (net/ipv4/af_inet.c:1398)[ 62.787605] skb_mac_gso_segment (net/core/gro.c:141)[ 62.791906] __skb_gso_segment (net/core/dev.c:3403 (discriminator 2))[ 62.800492] validate_xmit_skb (./include/linux/netdevice.h:4862net/core/dev.c:3659)[ 62.804695] validate_xmit_skb_list (net/core/dev.c:3710)[ 62.809158] sch_direct_xmit (net/sched/sch_generic.c:330)[ 62.813198] __dev_queue_xmit (net/core/dev.c:3805 net/core/dev.c:4210)net/netfilter/core.c:626)[ 62.821093] br_dev_queue_push_xmit (net/bridge/br_forward.c:55)[ 62.825652] maybe_deliver (net/bridge/br_forward.c:193)[ 62.829420] br_flood (net/bridge/br_forward.c:233)[ 62.832758] br_handle_frame_finish (net/bridge/br_input.c:215)[ 62.837403] br_handle_frame (net/bridge/br_input.c:298net/bridge/br_input.c:416)[ 62.851417] __netif_receive_skb_core.constprop.0 (net/core/dev.c:5387)[ 62.866114] __netif_receive_skb_list_core (net/core/dev.c:5570)[ 62.871367] netif_receive_skb_list_internal (net/core/dev.c:5638net/core/dev.c:5727)[ 62.876795] napi_complete_done (./include/linux/list.h:37./include/net/gro.h:434 ./include/net/gro.h:429 net/core/dev.c:6067)[ 62.881004] ixgbe_poll (drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:3191)[ 62.893534] __napi_poll (net/core/dev.c:6498)[ 62.897133] napi_threaded_poll (./include/linux/netpoll.h:89net/core/dev.c:6640)[ 62.905276] kthread (kernel/kthread.c:379)[ 62.913435] ret_from_fork (arch/x86/entry/entry_64.S:314)[ 62.917119] In the critical scenario, rx-gro-list GRO-ed packets are fed, via abridge, both to the local input path and to an egress device (tun).The segmentation of such packets unsafely writes to the cloned skbswith shared heads.This change addresses the issue by uncloning as needed theto-be-segmented skbs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: Protect reconfiguration of sb read-write from racing writesThe reconfigure / remount code takes a lot of effort to protectfilesystem's reconfiguration code from racing writes on remountingread-only. However during remounting read-only filesystem to read-writemode userspace writes can start immediately once we clear SB_RDONLYflag. This is inconvenient for example for ext4 because we need to dosome writes to the filesystem (such as preparation of quota files)before we can take userspace writes so we are clearing SB_RDONLY flagbefore we are fully ready to accept userpace writes and syzbot has founda way to exploit this [1]. Also as far as I'm reading the codethe filesystem remount code was protected from racing writes in thelegacy mount path by the mount's MNT_READONLY flag so this is relativelynew problem. It is actually fairly easy to protect remount read-writefrom racing writes using sb->s_readonly_remount flag so let's just dothat instead of having to workaround these races in the filesystem code.[1] https://lore.kernel.org/all/00000000000006a0df05f6667499@google.com/T/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: rcar_fdp1: Fix refcount leak in probe and remove functionrcar_fcp_get() take reference, which should be balanced withrcar_fcp_put(). Add missing rcar_fcp_put() in fdp1_remove andthe error paths of fdp1_probe() to fix this.[hverkuil: resolve merge conflict, remove() is now void]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: Fix memory leak in error path of kcm_sendmsg()syzbot reported a memory leak like below:BUG: memory leakunreferenced object 0xffff88810b088c00 (size 240): comm "syz-executor186", pid 5012, jiffies 4294943306 (age 13.680s) hex dump (first 32 bytes): 00 89 08 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] __alloc_skb+0x1ef/0x230 net/core/skbuff.c:634 [] alloc_skb include/linux/skbuff.h:1289 [inline] [] kcm_sendmsg+0x269/0x1050 net/kcm/kcmsock.c:815 [] sock_sendmsg_nosec net/socket.c:725 [inline] [] sock_sendmsg+0x56/0xb0 net/socket.c:748 [] ____sys_sendmsg+0x365/0x470 net/socket.c:2494 [] ___sys_sendmsg+0xc9/0x130 net/socket.c:2548 [] __sys_sendmsg+0xa6/0x120 net/socket.c:2577 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcdIn kcm_sendmsg(), kcm_tx_msg(head)->last_skb is used as a cursor to appendnewly allocated skbs to 'head'. If some bytes are copied, an error occurred,and jumped to out_error label, 'last_skb' is left unmodified. A laterkcm_sendmsg() will use an obsoleted 'last_skb' reference, corrupting the'head' frag_list and causing the leak.This patch fixes this issue by properly updating the last allocated skb in'last_skb'.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcu: dump vmalloc memory info safelyCurrently, for double invoke call_rcu(), will dump rcu_head objects memoryinfo, if the objects is not allocated from the slab allocator, thevmalloc_dump_obj() will be invoke and the vmap_area_lock spinlock need tobe held, since the call_rcu() can be invoked in interrupt context,therefore, there is a possibility of spinlock deadlock scenarios.And in Preempt-RT kernel, the rcutorture test also trigger the followinglockdep warning:BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0preempt_count: 1, expected: 0RCU nest depth: 1, expected: 13 locks held by swapper/0/1: #0: ffffffffb534ee80 (fullstop_mutex){+.+.}-{4:4}, at: torture_init_begin+0x24/0xa0 #1: ffffffffb5307940 (rcu_read_lock){....}-{1:3}, at: rcu_torture_init+0x1ec7/0x2370 #2: ffffffffb536af40 (vmap_area_lock){+.+.}-{3:3}, at: find_vmap_area+0x1f/0x70irq event stamp: 565512hardirqs last enabled at (565511): [] __call_rcu_common+0x218/0x940hardirqs last disabled at (565512): [] rcu_torture_init+0x20b2/0x2370softirqs last enabled at (399112): [] __local_bh_enable_ip+0x126/0x170softirqs last disabled at (399106): [] inet_register_protosw+0x9/0x1d0Preemption disabled at:[] rcu_torture_init+0x1f13/0x2370CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.5.0-rc4-rt2-yocto-preempt-rt+ #15Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x68/0xb0 dump_stack+0x14/0x20 __might_resched+0x1aa/0x280 ? __pfx_rcu_torture_err_cb+0x10/0x10 rt_spin_lock+0x53/0x130 ? find_vmap_area+0x1f/0x70 find_vmap_area+0x1f/0x70 vmalloc_dump_obj+0x20/0x60 mem_dump_obj+0x22/0x90 __call_rcu_common+0x5bf/0x940 ? debug_smp_processor_id+0x1b/0x30 call_rcu_hurry+0x14/0x20 rcu_torture_init+0x1f82/0x2370 ? __pfx_rcu_torture_leak_cb+0x10/0x10 ? __pfx_rcu_torture_leak_cb+0x10/0x10 ? __pfx_rcu_torture_init+0x10/0x10 do_one_initcall+0x6c/0x300 ? debug_smp_processor_id+0x1b/0x30 kernel_init_freeable+0x2b9/0x540 ? __pfx_kernel_init+0x10/0x10 kernel_init+0x1f/0x150 ret_from_fork+0x40/0x50 ? __pfx_kernel_init+0x10/0x10 ret_from_fork_asm+0x1b/0x30 The previous patch fixes this by using the deadlock-safe best-effortversion of find_vm_area. However, in case of failure print the fact thatthe pointer was a vmalloc pointer so that we print at least something.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix incorrect splitting in btrfs_drop_extent_map_rangeIn production we were seeing a variety of WARN_ON()'s in the extent_mapcode, specifically in btrfs_drop_extent_map_range() when we have to calladd_extent_mapping() for our second split.Consider the following extent map layout PINNED [0 16K) [32K, 48K)and then we call btrfs_drop_extent_map_range for [0, 36K), withskip_pinned == true. The initial loop will have start = 0 end = 36K len = 36Kwe will find the [0, 16k) extent, but since we are pinned we will skipit, which has this code start = em_end; if (end != (u64)-1) len = start + len - em_end;em_end here is 16K, so now the values are start = 16K len = 16K + 36K - 16K = 36Klen should instead be 20K. This is a problem when we find the nextextent at [32K, 48K), we need to split this extent to leave [36K, 48k),however the code for the split looks like this split->start = start + len; split->len = em_end - (start + len);In this case we have em_end = 48K split->start = 16K + 36K // this should be 16K + 20K split->len = 48K - (16K + 36K) // this overflows as 16K + 36K is 52Kand now we have an invalid extent_map in the tree that potentiallyoverlaps other entries in the extent map. Even in the non-overlappingcase we will have split->start set improperly, which will cause problemswith any block related calculations.We don't actually need len in this loop, we can simply use end as ourend point, and only adjust start up when we find a pinned extent we needto skip.Adjust the logic to do this, which keeps us from inserting an invalidextent map.We only skip_pinned in the relocation case, so this is relatively rare,except in the case where you are running relocation a lot, which canhappen with auto relocation on.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to drop all dirty pages during umount() if cp_error is setxfstest generic/361 reports a bug as below:f2fs_bug_on(sbi, sbi->fsync_node_num);kernel BUG at fs/f2fs/super.c:1627!RIP: 0010:f2fs_put_super+0x3a8/0x3b0Call Trace: generic_shutdown_super+0x8c/0x1b0 kill_block_super+0x2b/0x60 kill_f2fs_super+0x87/0x110 deactivate_locked_super+0x39/0x80 deactivate_super+0x46/0x50 cleanup_mnt+0x109/0x170 __cleanup_mnt+0x16/0x20 task_work_run+0x65/0xa0 exit_to_user_mode_prepare+0x175/0x190 syscall_exit_to_user_mode+0x25/0x50 do_syscall_64+0x4c/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcDuring umount(), if cp_error is set, f2fs_wait_on_all_pages() shouldnot stop waiting all F2FS_WB_CP_DATA pages to be writebacked, otherwise,fsync_node_num can be non-zero after f2fs_wait_on_all_pages() causingthis bug.In this case, to avoid deadloop in f2fs_wait_on_all_pages(), it needsto drop all dirty pages rather than redirtying them.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-af: Add validation for lmac typeUpon physical link change, firmware reports to the kernel about thechange along with the details like speed, lmac_type_id, etc.Kernel derives lmac_type based on lmac_type_id received from firmware.In a few scenarios, firmware returns an invalid lmac_type_id, whichis resulting in below kernel panic. This patch adds the missingvalidation of the lmac_type_id field.Internal error: Oops: 96000005 [#1] PREEMPT SMP[ 35.321595] Modules linked in:[ 35.328982] CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted5.4.210-g2e3169d8e1bc-dirty #17[ 35.337014] Hardware name: Marvell CN103XX board (DT)[ 35.344297] Workqueue: events work_for_cpu_fn[ 35.352730] pstate: 40400089 (nZcv daIf +PAN -UAO)[ 35.360267] pc : strncpy+0x10/0x30[ 35.366595] lr : cgx_link_change_handler+0x90/0x180
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: core: remove unnecessary frame_sz check in bpf_xdp_adjust_tail()Syzkaller reported the following issue:=======================================Too BIG xdp->frame_sz = 131072WARNING: CPU: 0 PID: 5020 at net/core/filter.c:4121 ____bpf_xdp_adjust_tail net/core/filter.c:4121 [inline]WARNING: CPU: 0 PID: 5020 at net/core/filter.c:4121 bpf_xdp_adjust_tail+0x466/0xa10 net/core/filter.c:4103...Call Trace: bpf_prog_4add87e5301a4105+0x1a/0x1c __bpf_prog_run include/linux/filter.h:600 [inline] bpf_prog_run_xdp include/linux/filter.h:775 [inline] bpf_prog_run_generic_xdp+0x57e/0x11e0 net/core/dev.c:4721 netif_receive_generic_xdp net/core/dev.c:4807 [inline] do_xdp_generic+0x35c/0x770 net/core/dev.c:4866 tun_get_user+0x2340/0x3ca0 drivers/net/tun.c:1919 tun_chr_write_iter+0xe8/0x210 drivers/net/tun.c:2043 call_write_iter include/linux/fs.h:1871 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x650/0xe40 fs/read_write.c:584 ksys_write+0x12f/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdxdp->frame_sz > PAGE_SIZE check was introduced in commit c8741e2bfe87("xdp: Allow bpf_xdp_adjust_tail() to grow packet size"). But JesperDangaard Brouer noted that after introducing thexdp_init_buff() which all XDP driver use - it's safe to remove thischeck. The original intend was to catch cases where XDP drivers havenot been updated to use xdp.frame_sz, but that is not longer a concern(since xdp_init_buff).Running the initial syzkaller repro it was discovered that thecontiguous physical memory allocation is used for both xdp paths intun_get_user(), e.g. tun_build_skb() and tun_alloc_skb(). It was alsostated by Jesper Dangaard Brouer that XDP canwork on higher order pages, as long as this is contiguous physicalmemory (e.g. a page).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_sdei: Fix sleep from invalid context BUGRunning a preempt-rt (v6.2-rc3-rt1) based kernel on an Ampere Altratriggers: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 24, name: cpuhp/0 preempt_count: 0, expected: 0 RCU nest depth: 0, expected: 0 3 locks held by cpuhp/0/24: #0: ffffda30217c70d0 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248 #1: ffffda30217c7120 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248 #2: ffffda3021c711f0 (sdei_list_lock){....}-{3:3}, at: sdei_cpuhp_up+0x3c/0x130 irq event stamp: 36 hardirqs last enabled at (35): [] finish_task_switch+0xb4/0x2b0 hardirqs last disabled at (36): [] cpuhp_thread_fun+0x21c/0x248 softirqs last enabled at (0): [] copy_process+0x63c/0x1ac0 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 0 PID: 24 Comm: cpuhp/0 Not tainted 5.19.0-rc3-rt5-[...] Hardware name: WIWYNN Mt.Jade Server [...] Call trace: dump_backtrace+0x114/0x120 show_stack+0x20/0x70 dump_stack_lvl+0x9c/0xd8 dump_stack+0x18/0x34 __might_resched+0x188/0x228 rt_spin_lock+0x70/0x120 sdei_cpuhp_up+0x3c/0x130 cpuhp_invoke_callback+0x250/0xf08 cpuhp_thread_fun+0x120/0x248 smpboot_thread_fn+0x280/0x320 kthread+0x130/0x140 ret_from_fork+0x10/0x20sdei_cpuhp_up() is called in the STARTING hotplug section,which runs with interrupts disabled. Use a CPUHP_AP_ONLINE_DYN entryinstead to execute the cpuhp cb later, with preemption enabled.SDEI originally got its own cpuhp slot to allow interactingwith perf. It got superseded by pNMI and this early slot is notrelevant anymore. [1]Some SDEI calls (e.g. SDEI_1_0_FN_SDEI_PE_MASK) take actions on thecalling CPU. It is checked that preemption is disabled for them._ONLINE cpuhp cb are executed in the 'per CPU hotplug thread'.Preemption is enabled in those threads, but their cpumask is limitedto 1 CPU.Move 'WARN_ON_ONCE(preemptible())' statements so that SDEI cpuhp cbdon't trigger them.Also add a check for the SDEI_1_0_FN_SDEI_PRIVATE_RESET SDEI callwhich acts on the calling CPU.[1]:https://lore.kernel.org/all/5813b8c5-ae3e-87fd-fccc-94c9cd08816d@arm.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:of: unittest: fix null pointer dereferencing in of_unittest_find_node_by_name()when kmalloc() fail to allocate memory in kasprintf(), nameor full_name will be NULL, strcmp() will causenull pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix issue in verifying allow_ptr_leaksAfter we converted the capabilities of our networking-bpf program fromcap_sys_admin to cap_net_admin+cap_bpf, our networking-bpf programfailed to start. Because it failed the bpf verifier, and the error logis "R3 pointer comparison prohibited".A simple reproducer as follows,SEC("cls-ingress")int ingress(struct __sk_buff *skb){ struct iphdr *iph = (void *)(long)skb->data + sizeof(struct ethhdr); if ((long)(iph + 1) > (long)skb->data_end) return TC_ACT_STOLEN; return TC_ACT_OK;}Per discussion with Yonghong and Alexei [1], comparison of two packetpointers is not a pointer leak. This patch fixes it.Our local kernel is 6.1.y and we expect this fix to be backported to6.1.y, so stable is CCed.[1]. https://lore.kernel.org/bpf/CAADnVQ+Nmspr7Si+pxWn8zkE7hX-7s93ugwC+94aXSy4uQ9vBg@mail.gmail.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsit: Free cmds before session freeCommands from recovery entries are freed after session has been closed.That leads to use-after-free at command free or NPE with such call trace:Time2Retain timer expired for SID: 1, cleaning up iSCSI session.BUG: kernel NULL pointer dereference, address: 0000000000000140RIP: 0010:sbitmap_queue_clear+0x3a/0xa0Call Trace: target_release_cmd_kref+0xd1/0x1f0 [target_core_mod] transport_generic_free_cmd+0xd1/0x180 [target_core_mod] iscsit_free_cmd+0x53/0xd0 [iscsi_target_mod] iscsit_free_connection_recovery_entries+0x29d/0x320 [iscsi_target_mod] iscsit_close_session+0x13a/0x140 [iscsi_target_mod] iscsit_check_post_dataout+0x440/0x440 [iscsi_target_mod] call_timer_fn+0x24/0x140Move cleanup of recovery enrties to before session freeing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: 8250: Fix oops for port->pm on uart_change_pm()Unloading a hardware specific 8250 driver can produce error "Unable tohandle kernel paging request at virtual address" about ten seconds afterunloading the driver. This happens on uart_hangup() callinguart_change_pm().Turns out commit 04e82793f068 ("serial: 8250: Reinit port->pm on portspecific driver unbind") was only a partial fix. If the hardware specificdriver has initialized port->pm function, we need to clear port->pm too.Just reinitializing port->ops does not do this. Otherwise serial8250_pm()will call port->pm() instead of serial8250_do_pm().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: avoid a NULL dereference with unsupported widgetsIf an IPC4 topology contains an unsupported widget, its .module_infofield won't be set, then sof_ipc4_route_setup() will cause a kernelOops trying to dereference it. Add a check for such cases.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix potential panic dues to unprotected smc_llc_srv_add_link()There is a certain chance to trigger the following panic:PID: 5900 TASK: ffff88c1c8af4100 CPU: 1 COMMAND: "kworker/1:48" #0 [ffff9456c1cc79a0] machine_kexec at ffffffff870665b7 #1 [ffff9456c1cc79f0] __crash_kexec at ffffffff871b4c7a #2 [ffff9456c1cc7ab0] crash_kexec at ffffffff871b5b60 #3 [ffff9456c1cc7ac0] oops_end at ffffffff87026ce7 #4 [ffff9456c1cc7ae0] page_fault_oops at ffffffff87075715 #5 [ffff9456c1cc7b58] exc_page_fault at ffffffff87ad0654 #6 [ffff9456c1cc7b80] asm_exc_page_fault at ffffffff87c00b62 [exception RIP: ib_alloc_mr+19] RIP: ffffffffc0c9cce3 RSP: ffff9456c1cc7c38 RFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000004 RDX: 0000000000000010 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88c1ea281d00 R8: 000000020a34ffff R9: ffff88c1350bbb20 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000010 R14: ffff88c1ab040a50 R15: ffff88c1ea281d00 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff9456c1cc7c60] smc_ib_get_memory_region at ffffffffc0aff6df [smc] #8 [ffff9456c1cc7c88] smcr_buf_map_link at ffffffffc0b0278c [smc] #9 [ffff9456c1cc7ce0] __smc_buf_create at ffffffffc0b03586 [smc]The reason here is that when the server tries to create a second link,smc_llc_srv_add_link() has no protection and may add a new link tolink group. This breaks the security environment protected byllc_conf_mutex.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: mtk_eth_soc: fix possible NULL pointer dereference in mtk_hwlro_get_fdir_all()rule_locs is allocated in ethtool_get_rxnfc and the size is determined byrule_cnt from user space. So rule_cnt needs to be check before usingrule_locs to avoid NULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcuscale: Move rcu_scale_writer() schedule_timeout_uninterruptible() to _idle()The rcuscale.holdoff module parameter can be used to delay the startof rcu_scale_writer() kthread. However, the hung-task timeout willtrigger when the timeout specified by rcuscale.holdoff is greater thanhung_task_timeout_secs:runqemu kvm nographic slirp qemuparams="-smp 4 -m 2048M"bootparams="rcuscale.shutdown=0 rcuscale.holdoff=300"[ 247.071753] INFO: task rcu_scale_write:59 blocked for more than 122 seconds.[ 247.072529] Not tainted 6.4.0-rc1-00134-gb9ed6de8d4ff #7[ 247.073400] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.[ 247.074331] task:rcu_scale_write state:D stack:30144 pid:59 ppid:2 flags:0x00004000[ 247.075346] Call Trace:[ 247.075660] [ 247.075965] __schedule+0x635/0x1280[ 247.076448] ? __pfx___schedule+0x10/0x10[ 247.076967] ? schedule_timeout+0x2dc/0x4d0[ 247.077471] ? __pfx_lock_release+0x10/0x10[ 247.078018] ? enqueue_timer+0xe2/0x220[ 247.078522] schedule+0x84/0x120[ 247.078957] schedule_timeout+0x2e1/0x4d0[ 247.079447] ? __pfx_schedule_timeout+0x10/0x10[ 247.080032] ? __pfx_rcu_scale_writer+0x10/0x10[ 247.080591] ? __pfx_process_timeout+0x10/0x10[ 247.081163] ? __pfx_sched_set_fifo_low+0x10/0x10[ 247.081760] ? __pfx_rcu_scale_writer+0x10/0x10[ 247.082287] rcu_scale_writer+0x6b1/0x7f0[ 247.082773] ? mark_held_locks+0x29/0xa0[ 247.083252] ? __pfx_rcu_scale_writer+0x10/0x10[ 247.083865] ? __pfx_rcu_scale_writer+0x10/0x10[ 247.084412] kthread+0x179/0x1c0[ 247.084759] ? __pfx_kthread+0x10/0x10[ 247.085098] ret_from_fork+0x2c/0x50[ 247.085433] This commit therefore replaces schedule_timeout_uninterruptible() withschedule_timeout_idle().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix potential oops in cifs_oplock_breakWith deferred close we can have closes that race with lease breaks,and so with the current checks for whether to send the lease response,oplock_response(), this can mean that an unmount (kill_sb) can occurjust before we were checking if the tcon->ses is valid. See below:[Fri Aug 4 04:12:50 2023] RIP: 0010:cifs_oplock_break+0x1f7/0x5b0 [cifs][Fri Aug 4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 c0 e9 02 48 89 45 b8 41 89 cf e8 3e f5 ff ff 4c 89 f7 41 83 e7 01 e8 82 b3 03 f2 49 8b 45 50 48 85 c0 74 5e <48> 83 78 60 00 74 57 45 84 ff 75 52 48 8b 43 98 48 83 eb 68 48 39[Fri Aug 4 04:12:50 2023] RSP: 0018:ffffb30607ddbdf8 EFLAGS: 00010206[Fri Aug 4 04:12:50 2023] RAX: 632d223d32612022 RBX: ffff97136944b1e0 RCX: 0000000080100009[Fri Aug 4 04:12:50 2023] RDX: 0000000000000001 RSI: 0000000080100009 RDI: ffff97136944b188[Fri Aug 4 04:12:50 2023] RBP: ffffb30607ddbe58 R08: 0000000000000001 R09: ffffffffc08e0900[Fri Aug 4 04:12:50 2023] R10: 0000000000000001 R11: 000000000000000f R12: ffff97136944b138[Fri Aug 4 04:12:50 2023] R13: ffff97149147c000 R14: ffff97136944b188 R15: 0000000000000000[Fri Aug 4 04:12:50 2023] FS: 0000000000000000(0000) GS:ffff9714f7c00000(0000) knlGS:0000000000000000[Fri Aug 4 04:12:50 2023] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[Fri Aug 4 04:12:50 2023] CR2: 00007fd8de9c7590 CR3: 000000011228e000 CR4: 0000000000350ef0[Fri Aug 4 04:12:50 2023] Call Trace:[Fri Aug 4 04:12:50 2023] [Fri Aug 4 04:12:50 2023] process_one_work+0x225/0x3d0[Fri Aug 4 04:12:50 2023] worker_thread+0x4d/0x3e0[Fri Aug 4 04:12:50 2023] ? process_one_work+0x3d0/0x3d0[Fri Aug 4 04:12:50 2023] kthread+0x12a/0x150[Fri Aug 4 04:12:50 2023] ? set_kthread_struct+0x50/0x50[Fri Aug 4 04:12:50 2023] ret_from_fork+0x22/0x30[Fri Aug 4 04:12:50 2023] To fix this change the ordering of the checks before sending the oplock_responseto first check if the openFileList is empty.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Add missing gfx11 MQD manager callbacksmqd_stride function was introduced in commit 2f77b9a242a2("drm/amdkfd: Update MQD management on multi XCC setup")but not assigned for gfx11. Fixes a NULL dereference in debugfs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau/kms/nv50-: init hpd_irq_lock for PIOR DPFixes OOPS on boards with ANX9805 DP encoders.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: release path before inode lookup during the ino lookup ioctlDuring the ino lookup ioctl we can end up calling btrfs_iget() to get aninode reference while we are holding on a root's btree. If btrfs_iget()needs to lookup the inode from the root's btree, because it's notcurrently loaded in memory, then it will need to lock another or thesame path in the same root btree. This may result in a deadlock andtrigger the following lockdep splat: WARNING: possible circular locking dependency detected 6.5.0-rc7-syzkaller-00004-gf7757129e3de #0 Not tainted ------------------------------------------------------ syz-executor277/5012 is trying to acquire lock: ffff88802df41710 (btrfs-tree-01){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 but task is already holding lock: ffff88802df418e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (btrfs-tree-00){++++}-{3:3}: down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645 __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 btrfs_search_slot+0x13a4/0x2f80 fs/btrfs/ctree.c:2302 btrfs_init_root_free_objectid+0x148/0x320 fs/btrfs/disk-io.c:4955 btrfs_init_fs_root fs/btrfs/disk-io.c:1128 [inline] btrfs_get_root_ref+0x5ae/0xae0 fs/btrfs/disk-io.c:1338 btrfs_get_fs_root fs/btrfs/disk-io.c:1390 [inline] open_ctree+0x29c8/0x3030 fs/btrfs/disk-io.c:3494 btrfs_fill_super+0x1c7/0x2f0 fs/btrfs/super.c:1154 btrfs_mount_root+0x7e0/0x910 fs/btrfs/super.c:1519 legacy_get_tree+0xef/0x190 fs/fs_context.c:611 vfs_get_tree+0x8c/0x270 fs/super.c:1519 fc_mount fs/namespace.c:1112 [inline] vfs_kern_mount+0xbc/0x150 fs/namespace.c:1142 btrfs_mount+0x39f/0xb50 fs/btrfs/super.c:1579 legacy_get_tree+0xef/0x190 fs/fs_context.c:611 vfs_get_tree+0x8c/0x270 fs/super.c:1519 do_new_mount+0x28f/0xae0 fs/namespace.c:3335 do_mount fs/namespace.c:3675 [inline] __do_sys_mount fs/namespace.c:3884 [inline] __se_sys_mount+0x2d9/0x3c0 fs/namespace.c:3861 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd -> #0 (btrfs-tree-01){++++}-{3:3}: check_prev_add kernel/locking/lockdep.c:3142 [inline] check_prevs_add kernel/locking/lockdep.c:3261 [inline] validate_chain kernel/locking/lockdep.c:3876 [inline] __lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144 lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761 down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645 __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 btrfs_tree_read_lock fs/btrfs/locking.c:142 [inline] btrfs_read_lock_root_node+0x292/0x3c0 fs/btrfs/locking.c:281 btrfs_search_slot_get_root fs/btrfs/ctree.c:1832 [inline] btrfs_search_slot+0x4ff/0x2f80 fs/btrfs/ctree.c:2154 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:412 btrfs_read_locked_inode fs/btrfs/inode.c:3892 [inline] btrfs_iget_path+0x2d9/0x1520 fs/btrfs/inode.c:5716 btrfs_search_path_in_tree_user fs/btrfs/ioctl.c:1961 [inline] btrfs_ioctl_ino_lookup_user+0x77a/0xf50 fs/btrfs/ioctl.c:2105 btrfs_ioctl+0xb0b/0xd40 fs/btrfs/ioctl.c:4683 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl+0xf8/0x170 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd other info ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tls: avoid hanging tasks on the tx_locksyzbot sent a hung task report and Eric explains that adversarialreceiver may keep RWIN at 0 for a long time, so we are not guaranteedto make forward progress. Thread which took tx_lock and went to sleepmay not release tx_lock for hours. Use interruptible sleep wherepossible and reschedule the work if it can't take the lock.Testing: existing selftest passes
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: use smc_lgr_list.lock to protect smc_lgr_list.list iterate in smcr_port_addWhile doing smcr_port_add, there maybe linkgroup add into or deletefrom smc_lgr_list.list at the same time, which may result kernel crash.So, use smc_lgr_list.lock to protect smc_lgr_list.list iterate insmcr_port_add.The crash calltrace show below:BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: 0000 [#1] SMP NOPTICPU: 0 PID: 559726 Comm: kworker/0:92 Kdump: loaded Tainted: GHardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 449e491 04/01/2014Workqueue: events smc_ib_port_event_work [smc]RIP: 0010:smcr_port_add+0xa6/0xf0 [smc]RSP: 0000:ffffa5a2c8f67de0 EFLAGS: 00010297RAX: 0000000000000001 RBX: ffff9935e0650000 RCX: 0000000000000000RDX: 0000000000000010 RSI: ffff9935e0654290 RDI: ffff9935c8560000RBP: 0000000000000000 R08: 0000000000000000 R09: ffff9934c0401918R10: 0000000000000000 R11: ffffffffb4a5c278 R12: ffff99364029aae4R13: ffff99364029aa00 R14: 00000000ffffffed R15: ffff99364029ab08FS: 0000000000000000(0000) GS:ffff994380600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 0000000f06a10003 CR4: 0000000002770ef0PKRU: 55555554Call Trace: smc_ib_port_event_work+0x18f/0x380 [smc] process_one_work+0x19b/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x114/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x1f/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl/pmem: Fix nvdimm registration racesA loop of the form: while true; do modprobe cxl_pci; modprobe -r cxl_pci; done...fails with the following crash signature: BUG: kernel NULL pointer dereference, address: 0000000000000040 [..] RIP: 0010:cxl_internal_send_cmd+0x5/0xb0 [cxl_core] [..] Call Trace: cxl_pmem_ctl+0x121/0x240 [cxl_pmem] nvdimm_get_config_data+0xd6/0x1a0 [libnvdimm] nd_label_data_init+0x135/0x7e0 [libnvdimm] nvdimm_probe+0xd6/0x1c0 [libnvdimm] nvdimm_bus_probe+0x7a/0x1e0 [libnvdimm] really_probe+0xde/0x380 __driver_probe_device+0x78/0x170 driver_probe_device+0x1f/0x90 __device_attach_driver+0x85/0x110 bus_for_each_drv+0x7d/0xc0 __device_attach+0xb4/0x1e0 bus_probe_device+0x9f/0xc0 device_add+0x445/0x9c0 nd_async_device_register+0xe/0x40 [libnvdimm] async_run_entry_fn+0x30/0x130...namely that the bottom half of async nvdimm device registration runsafter the CXL has already torn down the context that cxl_pmem_ctl()needs. Unlike the ACPI NFIT case that benefits from launching multiplenvdimm device registrations in parallel from those listed in the table,CXL is already marked PROBE_PREFER_ASYNCHRONOUS. So provide for asynchronous registration path to preclude this scenario.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: jq is a command-line JSON processor. In versions up to and including 1.7.1, an integer overflow arises when assigning value using an index of 2147483647, the signed integer limit. This causes a denial of service. Commit de21386681c0df0104a99d9d09db23a9b2a78b1e contains a patch for the issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()Syzkaller reported [1] hitting a warning after failing to allocateresources for skb in hsr_init_skb(). Since a WARN_ONCE() call willnot help much in this case, it might be prudent to switch tonetdev_warn_once(). At the very least it will suppress syzkallerreports such as [1].Just in case, use netdev_warn_once() in send_prp_supervision_frame()for similar reasons.[1]HSR: Could not send supervision frameWARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294...Call Trace: hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382 call_timer_fn+0x193/0x590 kernel/time/timer.c:1700 expire_timers kernel/time/timer.c:1751 [inline] __run_timers+0x764/0xb20 kernel/time/timer.c:2022 run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035 __do_softirq+0x21a/0x8de kernel/softirq.c:553 invoke_softirq kernel/softirq.c:427 [inline] __irq_exit_rcu kernel/softirq.c:632 [inline] irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644 sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649...This issue is also found in older kernels (at least up to 5.10).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: veth: clear GRO when clearing XDP even when downveth sets NETIF_F_GRO automatically when XDP is enabled,because both features use the same NAPI machinery.The logic to clear NETIF_F_GRO sits in veth_disable_xdp() whichis called both on ndo_stop and when XDP is turned off.To avoid the flag from being cleared when the device is broughtdown, the clearing is skipped when IFF_UP is not set.Bringing the device down should indeed not modify its features.Unfortunately, this means that clearing is also skipped whenXDP is disabled _while_ the device is down. And there's nothingon the open path to bring the device features back into sync.IOW if user enables XDP, disables it and then brings the deviceup we'll end up with a stray GRO flag set but no NAPI instances.We don't depend on the GRO flag on the datapath, so the datapathwon't crash. We will crash (or hang), however, next time featuresare sync'ed (either by user via ethtool or peer changing its config).The GRO flag will go away, and veth will try to disable the NAPIs.But the open path never created them since XDP was off, the GRO flagwas a stray. If NAPI was initialized before we'll hang in napi_disable().If it never was we'll crash trying to stop uninitialized hrtimer.Move the GRO flag updates to the XDP enable / disable paths,instead of mixing them with the ndo_open / ndo_close paths.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshapeFor raid456, if reshape is still in progress, then IO across reshapeposition will wait for reshape to make progress. However, for dm-raid,in following cases reshape will never make progress hence IO will hang:1) the array is read-only;2) MD_RECOVERY_WAIT is set;3) MD_RECOVERY_FROZEN is set;After commit c467e97f079f ("md/raid6: use valid sector values to determineif an I/O should wait on the reshape") fix the problem that IO acrossreshape position doesn't wait for reshape, the dm-raid testshell/lvconvert-raid-reshape.sh start to hang:[root@fedora ~]# cat /proc/979/stack[<0>] wait_woken+0x7d/0x90[<0>] raid5_make_request+0x929/0x1d70 [raid456][<0>] md_handle_request+0xc2/0x3b0 [md_mod][<0>] raid_map+0x2c/0x50 [dm_raid][<0>] __map_bio+0x251/0x380 [dm_mod][<0>] dm_submit_bio+0x1f0/0x760 [dm_mod][<0>] __submit_bio+0xc2/0x1c0[<0>] submit_bio_noacct_nocheck+0x17f/0x450[<0>] submit_bio_noacct+0x2bc/0x780[<0>] submit_bio+0x70/0xc0[<0>] mpage_readahead+0x169/0x1f0[<0>] blkdev_readahead+0x18/0x30[<0>] read_pages+0x7c/0x3b0[<0>] page_cache_ra_unbounded+0x1ab/0x280[<0>] force_page_cache_ra+0x9e/0x130[<0>] page_cache_sync_ra+0x3b/0x110[<0>] filemap_get_pages+0x143/0xa30[<0>] filemap_read+0xdc/0x4b0[<0>] blkdev_read_iter+0x75/0x200[<0>] vfs_read+0x272/0x460[<0>] ksys_read+0x7a/0x170[<0>] __x64_sys_read+0x1c/0x30[<0>] do_syscall_64+0xc6/0x230[<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74This is because reshape can't make progress.For md/raid, the problem doesn't exist because register new sync_threaddoesn't rely on the IO to be done any more:1) If array is read-only, it can switch to read-write by ioctl/sysfs;2) md/raid never set MD_RECOVERY_WAIT;3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold 'reconfig_mutex', hence it can be cleared and reshape can continue by sysfs api 'sync_action'.However, I'm not sure yet how to avoid the problem in dm-raid yet. Thispatch on the one hand make sure raid_message() can't changesync_thread() through raid_message() after presuspend(), on the otherhand detect the above 3 cases before wait for IO do be done indm_suspend(), and let dm-raid requeue those IO.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: mediatek: Do a runtime PM get on controllers during probemt8183-mfgcfg has a mutual dependency with genpd during the probingstage, which leads to a deadlock in the following call stack:CPU0: genpd_lock --> clk_prepare_lockgenpd_power_off_work_fn() genpd_lock() generic_pm_domain::power_off() clk_unprepare() clk_prepare_lock()CPU1: clk_prepare_lock --> genpd_lockclk_register() __clk_core_init() clk_prepare_lock() clk_pm_runtime_get() genpd_lock()Do a runtime PM get at the probe function to make sure clk_register()won't acquire the genpd lock. Instead of only modifying mt8183-mfgcfg,do this on all mediatek clock controller probings because we don'tbelieve this would cause any regression.Verified on MT8183 and MT8192 Chromebooks.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()'The 'stream' pointer is used in dcn10_set_output_transfer_func() beforethe check if 'stream' is NULL.Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/dm-raid: don't call md_reap_sync_thread() directlyCurrently md_reap_sync_thread() is called from raid_message() directlywithout holding 'reconfig_mutex', this is definitely unsafe becausemd_reap_sync_thread() can change many fields that is protected by'reconfig_mutex'.However, hold 'reconfig_mutex' here is still problematic because thiswill cause deadlock, for example, commit 130443d60b1b ("md: refactoridle/frozen_sync_thread() to fix deadlock").Fix this problem by using stop_sync_thread() to unregister sync_thread,like md/raid did.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Skip do PCI error slot reset during RAS recoveryWhy: The PCI error slot reset maybe triggered after inject ue to UMC multi times, this caused system hang. [ 557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume [ 557.373718] [drm] PCIE GART of 512M enabled. [ 557.373722] [drm] PTB located at 0x0000031FED700000 [ 557.373788] [drm] VRAM is lost due to GPU reset! [ 557.373789] [drm] PSP is resuming... [ 557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset [ 557.547067] [drm] PCI error: detected callback, state(1)!! [ 557.547069] [drm] No support for XGMI hive yet... [ 557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter [ 557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations [ 557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered [ 557.610492] [drm] PCI error: slot reset callback!! ... [ 560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded! [ 560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded! [ 560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI [ 560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G OE 5.15.0-91-generic #101-Ubuntu [ 560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023 [ 560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu] [ 560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu] [ 560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff <48> 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00 [ 560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202 [ 560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0 [ 560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010 [ 560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08 [ 560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000 [ 560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000 [ 560.803889] FS: 0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000 [ 560.812973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0 [ 560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 560.843444] PKRU: 55555554 [ 560.846480] Call Trace: [ 560.849225] [ 560.851580] ? show_trace_log_lvl+0x1d6/0x2ea [ 560.856488] ? show_trace_log_lvl+0x1d6/0x2ea [ 560.861379] ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu] [ 560.867778] ? show_regs.part.0+0x23/0x29 [ 560.872293] ? __die_body.cold+0x8/0xd [ 560.876502] ? die_addr+0x3e/0x60 [ 560.880238] ? exc_general_protection+0x1c5/0x410 [ 560.885532] ? asm_exc_general_protection+0x27/0x30 [ 560.891025] ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu] [ 560.898323] amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu] [ 560.904520] process_one_work+0x228/0x3d0How: In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rtrs: Ensure 'ib_sge list' is accessibleMove the declaration of the 'ib_sge list' variable outside the'always_invalidate' block to ensure it remains accessible for usethroughout the function.Previously, 'ib_sge list' was declared within the 'always_invalidate'block, limiting its accessibility, then caused a'BUG: kernel NULL pointer dereference'[1]. ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2d0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? memcpy_orig+0xd5/0x140 rxe_mr_copy+0x1c3/0x200 [rdma_rxe] ? rxe_pool_get_index+0x4b/0x80 [rdma_rxe] copy_data+0xa5/0x230 [rdma_rxe] rxe_requester+0xd9b/0xf70 [rdma_rxe] ? finish_task_switch.isra.0+0x99/0x2e0 rxe_sender+0x13/0x40 [rdma_rxe] do_task+0x68/0x1e0 [rdma_rxe] process_one_work+0x177/0x330 worker_thread+0x252/0x390 ? __pfx_worker_thread+0x10/0x10This change ensures the variable is available for subsequent operationsthat require it.[1] https://lore.kernel.org/linux-rdma/6a1f3e8f-deb0-49f9-bc69-a9b03ecfcda7@fujitsu.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-iocost: do not WARN if iocg was already offlinedIn iocg_pay_debt(), warn is triggered if 'active_list' is empty, whichis intended to confirm iocg is active when it has debt. However, warncan be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn()is run at that time: WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0The warn in this situation is meaningless. Since this iocg is beingremoved, the state of the 'active_list' is irrelevant, and 'waitq_timer'is canceled after removing 'active_list' in ioc_pd_free(), which ensuresiocg is freed after iocg_waitq_timer_fn() returns.Therefore, add the check if iocg was already offlined to avoid warnwhen removing a blkcg or disk.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: fix overflow in blk_ioctl_discard()There is no check for overflow of 'start + len' in blk_ioctl_discard().Hung task occurs if submit an discard ioctl with the following param: start = 0x80000000000ff000, len = 0x8000000000fff000;Add the overflow validation now.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dpu: Add callback function pointer check before its callIn dpu_core_irq_callback_handler() callback function pointer is compared to NULL,but then callback function is unconditionally called by this pointer.Fix this bug by adding conditional return.Found by Linux Verification Center (linuxtesting.org) with SVACE.Patchwork: https://patchwork.freedesktop.org/patch/588237/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Fix userfaultfd_api to return EINVAL as expectedCurrently if we request a feature that is not set in the Kernel config wefail silently and return all the available features. However, the manpage indicates we should return an EINVAL.We need to fix this issue since we can end up with a Kernel warning shoulda program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel withthe config not set with this feature. [ 200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660 [ 200.820738] Modules linked in: [ 200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8 [ 200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022 [ 200.885052] RIP: 0010:zap_pte_range+0x43d/0x660
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cachefiles: cyclic allocation of msg_id to avoid reuseReusing the msg_id after a maliciously completed reopen request may causea read request to remain unprocessed and result in a hung, as shown below: t1 | t2 | t3-------------------------------------------------cachefiles_ondemand_select_req cachefiles_ondemand_object_is_close(A) cachefiles_ondemand_set_object_reopening(A) queue_work(fscache_object_wq, &info->work) ondemand_object_worker cachefiles_ondemand_init_object(A) cachefiles_ondemand_send_req(OPEN) // get msg_id 6 wait_for_completion(&req_A->done)cachefiles_ondemand_daemon_read // read msg_id 6 req_A cachefiles_ondemand_get_fd copy_to_user // Malicious completion msg_id 6 copen 6,-1 cachefiles_ondemand_copen complete(&req_A->done) // will not set the object to close // because ondemand_id && fd is valid. // ondemand_object_worker() is done // but the object is still reopening. // new open req_B cachefiles_ondemand_init_object(B) cachefiles_ondemand_send_req(OPEN) // reuse msg_id 6process_open_req copen 6,A.size // The expected failed copen was executed successfullyExpect copen to fail, and when it does, it closes fd, which sets theobject to close, and then close triggers reopen again. However, due tomsg_id reuse resulting in a successful copen, the anonymous fd is notclosed until the daemon exits. Therefore read requests waiting for reopento complete may trigger hung task.To avoid this issue, allocate the msg_id cyclically to avoid reusing themsg_id for a very short duration of time.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: avoid to reuse `hctx` not removed from cpuhp callback listIf the 'hctx' isn't removed from cpuhp callback list, we can't reuse it,otherwise use-after-free may be triggered.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/imx-irqsteer: Handle runtime power management correctlyThe power domain is automatically activated from clk_prepare(). However, oncertain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokessleeping functions, which triggers the 'scheduling while atomic' bug in thecontext switch path during device probing: BUG: scheduling while atomic: kworker/u13:1/48/0x00000002 Call trace: __schedule_bug+0x54/0x6c __schedule+0x7f0/0xa94 schedule+0x5c/0xc4 schedule_preempt_disabled+0x24/0x40 __mutex_lock.constprop.0+0x2c0/0x540 __mutex_lock_slowpath+0x14/0x20 mutex_lock+0x48/0x54 clk_prepare_lock+0x44/0xa0 clk_prepare+0x20/0x44 imx_irqsteer_resume+0x28/0xe0 pm_generic_runtime_resume+0x2c/0x44 __genpd_runtime_resume+0x30/0x80 genpd_runtime_resume+0xc8/0x2c0 __rpm_callback+0x48/0x1d8 rpm_callback+0x6c/0x78 rpm_resume+0x490/0x6b4 __pm_runtime_resume+0x50/0x94 irq_chip_pm_get+0x2c/0xa0 __irq_do_set_handler+0x178/0x24c irq_set_chained_handler_and_data+0x60/0xa4 mxc_gpio_probe+0x160/0x4b0Cure this by implementing the irq_bus_lock/sync_unlock() interrupt chipcallbacks and handle power management in them as they are invoked fromnon-atomic context.[ tglx: Rewrote change log, added Fixes tag ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: flow_dissector: use DEBUG_NET_WARN_ON_ONCEThe following splat is easy to reproduce upstream as well as in -stablekernels. Florian Westphal provided the following commit: d1dab4f71d37 ("net: add and use __skb_get_hash_symmetric_net")but this complementary fix has been also suggested by Willem de Bruijnand it can be easily backported to -stable kernel which consists inusing DEBUG_NET_WARN_ON_ONCE instead to silence the following splatgiven __skb_get_hash() is used by the nftables tracing infrastructure toto identify packets in traces.[69133.561393] ------------[ cut here ]------------[69133.561404] WARNING: CPU: 0 PID: 43576 at net/core/flow_dissector.c:1104 __skb_flow_dissect+0x134f/[...][69133.561944] CPU: 0 PID: 43576 Comm: socat Not tainted 6.10.0-rc7+ #379[69133.561959] RIP: 0010:__skb_flow_dissect+0x134f/0x2ad0[69133.561970] Code: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ffff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff <0f> 0b e9 20 f3 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8[69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246[69133.561988] RAX: 0000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19[69133.561994] RDX: dffffc0000000000 RSI: ffffc90000007388 RDI: ffff888103a1b418[69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000[69133.562007] R10: ffffc90000007388 R11: ffffffff810cface R12: ffff888103a1b400[69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28[69133.562020] FS: 00007f40f7131740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000[69133.562027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[69133.562033] CR2: 00007f40f7346ee0 CR3: 000000015d200001 CR4: 00000000001706f0[69133.562040] Call Trace:[69133.562044] [69133.562049] ? __warn+0x9f/0x1a0[ 1211.841384] ? __skb_flow_dissect+0x107e/0x2860[...][ 1211.841496] ? bpf_flow_dissect+0x160/0x160[ 1211.841753] __skb_get_hash+0x97/0x280[ 1211.841765] ? __skb_get_hash_symmetric+0x230/0x230[ 1211.841776] ? mod_find+0xbf/0xe0[ 1211.841786] ? get_stack_info_noinstr+0x12/0xe0[ 1211.841798] ? bpf_ksym_find+0x56/0xe0[ 1211.841807] ? __rcu_read_unlock+0x2a/0x70[ 1211.841819] nft_trace_init+0x1b9/0x1c0 [nf_tables][ 1211.841895] ? nft_trace_notify+0x830/0x830 [nf_tables][ 1211.841964] ? get_stack_info+0x2b/0x80[ 1211.841975] ? nft_do_chain_arp+0x80/0x80 [nf_tables][ 1211.842044] nft_do_chain+0x79c/0x850 [nf_tables]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init()Instead of getting the epc_features from pci_epc_get_features() API, usethe cached pci_epf_test::epc_features value to avoid the NULL check. Sincethe NULL check is already performed in pci_epf_test_bind(), having one morecheck in pci_epf_test_core_init() is redundant and it is not possible tohit the NULL pointer dereference.Also with commit a01e7214bef9 ("PCI: endpoint: Remove "core_init_notifier"flag"), 'epc_features' got dereferenced without the NULL check, leading tothe following false positive Smatch warning: drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed 'epc_features' could be null (see line 747)Thus, remove the redundant NULL check and also use the epc_features::{msix_capable/msi_capable} flags directly to avoid local variables.[kwilczynski: commit log]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/uv: Don't call folio_wait_writeback() without a folio referencefolio_wait_writeback() requires that no spinlocks are held and thata folio reference is held, as documented. After we dropped the PTL, thefolio could get freed concurrently. So grab a temporary reference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: mcast: wait for previous gc cycles when removing portsyzbot hit a use-after-free[1] which is caused because the bridge doesn'tmake sure that all previous garbage has been collected when removing aport. What happens is: CPU 1 CPU 2 start gc cycle remove port acquire gc lock first wait for lock call br_multicasg_gc() directly acquire lock now but free port the port can be freed while grp timers still runningMake sure all previous gc cycles have finished by using flush_work beforefreeing the port.[1] BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699 CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792 expire_timers kernel/time/timer.c:1843 [inline] __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417 __run_timer_base kernel/time/timer.c:2428 [inline] __run_timer_base kernel/time/timer.c:2421 [inline] run_timer_base+0x111/0x190 kernel/time/timer.c:2437
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Prevent unmapping active read buffersThe kms paths keep a persistent map active to read and compare the cursorbuffer. These maps can race with each other in simple scenario where:a) buffer "a" mapped for updateb) buffer "a" mapped for comparec) do the compared) unmap "a" for comparee) update the cursorf) unmap "a" for updateAt step "e" the buffer has been unmapped and the read contents is bogus.Prevent unmapping of active read buffers by simply keeping a count ofhow many paths have currently active maps and unmap only when the countreaches 0.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: protect XDP configuration with a mutexThe main threat to data consistency in ice_xdp() is a possible asynchronousPF reset. It can be triggered by a user or by TX timeout handler.XDP setup and PF reset code access the same resources in the followingsections:* ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked* ice_vsi_rebuild() for the PF VSI - not protected* ice_vsi_open() - already rtnl-lockedWith an unfortunate timing, such accesses can result in a crash such as theone below:[ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14[ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18[Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms[ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001[ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14[ +0.394718] ice 0000:b1:00.0: PTP reset successful[ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098[ +0.000045] #PF: supervisor read access in kernel mode[ +0.000023] #PF: error_code(0x0000) - not-present page[ +0.000023] PGD 0 P4D 0[ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI[ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1[ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021[ +0.000036] Workqueue: ice ice_service_task [ice][ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice][...][ +0.000013] Call Trace:[ +0.000016] [ +0.000014] ? __die+0x1f/0x70[ +0.000029] ? page_fault_oops+0x171/0x4f0[ +0.000029] ? schedule+0x3b/0xd0[ +0.000027] ? exc_page_fault+0x7b/0x180[ +0.000022] ? asm_exc_page_fault+0x22/0x30[ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice][ +0.000194] ice_free_tx_ring+0xe/0x60 [ice][ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice][ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice][ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice][ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice][ +0.000145] ice_rebuild+0x18c/0x840 [ice][ +0.000145] ? delay_tsc+0x4a/0xc0[ +0.000022] ? delay_tsc+0x92/0xc0[ +0.000020] ice_do_reset+0x140/0x180 [ice][ +0.000886] ice_service_task+0x404/0x1030 [ice][ +0.000824] process_one_work+0x171/0x340[ +0.000685] worker_thread+0x277/0x3a0[ +0.000675] ? preempt_count_add+0x6a/0xa0[ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50[ +0.000679] ? __pfx_worker_thread+0x10/0x10[ +0.000653] kthread+0xf0/0x120[ +0.000635] ? __pfx_kthread+0x10/0x10[ +0.000616] ret_from_fork+0x2d/0x50[ +0.000612] ? __pfx_kthread+0x10/0x10[ +0.000604] ret_from_fork_asm+0x1b/0x30[ +0.000604] The previous way of handling this through returning -EBUSY is not viable,particularly when destroying AF_XDP socket, because the kernel proceedswith removal anyway.There is plenty of code between those calls and there is no need to createa large critical section that covers all of them, same as there is no needto protect ice_vsi_rebuild() with rtnl_lock().Add xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp().Leaving unprotected sections in between would result in two states thathave to be considered:1. when the VSI is closed, but not yet rebuild2. when VSI is already rebuild, but not yet openThe latter case is actually already handled through !netif_running() case,we just need to adjust flag checking a little. The former one is not astrivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot ofhardware interaction happens, this can make adding/deleting rings exitwith an error. Luckily, VSI rebuild is pending and can apply newconfiguration for us in a managed fashion.Therefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING toindicate that ice_x---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ila: call nf_unregister_net_hooks() soonersyzbot found an use-after-free Read in ila_nf_input [1]Issue here is that ila_xlat_exit_net() frees the rhashtable,then call nf_unregister_net_hooks().It should be done in the reverse way, with a synchronize_rcu().This is a good match for a pre_exit() method.[1] BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline] BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline] BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup include/linux/rhashtable.h:604 [inline] rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6108 __napi_poll+0xcb/0x490 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6963 handle_softirqs+0x2c4/0x970 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:928 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 The buggy address belongs to the physical page:page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)page_type: 0xbfffffff(buddy)raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as freedpage last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493 prep_new_page mm/page_alloc.c:1501 [inline] get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439 __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695 __alloc_pages_node_noprof include/linux/gfp.h:269 [inline] alloc_pages_node_noprof include/linux/gfp.h:296 [inline] ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103 __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130 __do_kmalloc_node mm/slub.c:4146 [inline] __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164 __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650 bucket_table_alloc lib/rhashtable.c:186 [inline] rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071 ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613 ops_ini---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf: heaps: Fix off-by-one in CMA heap fault handlerUntil VM_DONTEXPAND was added in commit 1c1914d6e8c6 ("dma-buf: heaps:Don't track CMA dma-buf pages under RssFile") it was possible to obtaina mapping larger than the buffer size via mremap and bypass the overflowcheck in dma_buf_mmap_internal. When using such a mapping to attempt tofault past the end of the buffer, the CMA heap fault handler also checksthe fault offset against the buffer size, but gets the boundary wrong by1. Fix the boundary check so that we don't read off the end of the pagesarray and insert an arbitrary page in the mapping.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: Fix uaf in __timer_delete_syncThere are two paths to access mptcp_pm_del_add_timer, result in a racecondition: CPU1 CPU2 ==== ==== net_rx_action napi_poll netlink_sendmsg __napi_poll netlink_unicast process_backlog netlink_unicast_kernel __netif_receive_skb genl_rcv __netif_receive_skb_one_core netlink_rcv_skb NF_HOOK genl_rcv_msg ip_local_deliver_finish genl_family_rcv_msg ip_protocol_deliver_rcu genl_family_rcv_msg_doit tcp_v4_rcv mptcp_pm_nl_flush_addrs_doit tcp_v4_do_rcv mptcp_nl_remove_addrs_list tcp_rcv_established mptcp_pm_remove_addrs_and_subflows tcp_data_queue remove_anno_list_by_saddr mptcp_incoming_options mptcp_pm_del_add_timer mptcp_pm_del_add_timer kfree(entry)In remove_anno_list_by_saddr(running on CPU2), after leaving the criticalzone protected by "pm.lock", the entry will be released, which leads to theoccurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).Keeping a reference to add_timer inside the lock, and callingsk_stop_timer_sync() with this reference, instead of "entry->add_timer".Move list_del(&entry->list) to mptcp_pm_del_add_timer and inside the pm lock,do not directly access any members of the entry outside the pm lock, whichcan avoid similar "entry->x" uaf.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: stm32/cryp - call finalize with bh disabledThe finalize operation in interrupt mode produce a produces a spinlockrecursion warning. The reason is the fact that BH must be disabledduring this process.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: handle overlapped pclusters out of crafted images properlysyzbot reported a task hang issue due to a deadlock case where it iswaiting for the folio lock of a cached folio that will be used forcache I/Os.After looking into the crafted fuzzed image, I found it's formed withseveral overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384...Here, extent 0/1 are physically overlapped although it's entirely_impossible_ for normal filesystem images generated by mkfs.First, managed folios containing compressed data will be marked asup-to-date and then unlocked immediately (unlike in-place folios) whencompressed I/Os are complete. If physical blocks are not submitted inthe incremental order, there should be separate BIOs to avoid dependencyissues. However, the current code mis-arranges z_erofs_fill_bio_vec()and BIO submission which causes unexpected BIO waits.Second, managed folios will be connected to their own pclusters forefficient inter-queries. However, this is somewhat hard to implementeasily if overlapped big pclusters exist. Again, these only appear infuzzed images so let's simply fall back to temporary short-lived pagesfor correctness.Additionally, it justifies that referenced managed folios cannot betruncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidyup `struct z_erofs_bvec`") for simplicity although it shouldn't be anydifference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dlm: fix possible lkb_resource null dereferenceThis patch fixes a possible null pointer dereference when this function iscalled from request_lock() as lkb->lkb_resource is not assigned yet,only after validate_lock_args() by calling attach_lkb(). Another issueis that a resource name could be a non printable bytearray and we cannotassume to be ASCII coded.The log functionality is probably never being hit when DLM is used innormal way and no debug logging is enabled. The null pointer dereferencecan only occur on a new created lkb that does not have the resourceassigned yet, it probably never hits the null pointer dereference but weshould be sure that other changes might not change this behaviour and weactually can hit the mentioned null pointer dereference.In this patch we just drop the printout of the resource name, the lkb idis enough to make a possible connection to a resource name if thisexists.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bcache: revert replacing IS_ERR_OR_NULL with IS_ERR againCommit 028ddcac477b ("bcache: Remove unnecessary NULL point check innode allocations") leads a NULL pointer deference in cache_set_flush().1721 if (!IS_ERR_OR_NULL(c->root))1722 list_add(&c->root->list, &c->btree_cache);>From the above code in cache_set_flush(), if previous registration codefails before allocating c->root, it is possible c->root is NULL as whatit is initialized. __bch_btree_node_alloc() never returns NULL butc->root is possible to be NULL at above line 1721.This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/tracing: Fix a potential TP_printk UAFThe commitafd2627f727b ("tracing: Check "%s" dereference via the field and not the TP_printk format")exposes potential UAFs in the xe_bo_move trace event.Fix those by avoiding dereferencing thexe_mem_type_to_name[] array at TP_printk time.Since some code refactoring has taken place, explicit backporting maybe needed for kernels older than 6.10.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null-initialized variables[WHAT & HOW]drr_timing and subvp_pipe are initialized to null and they are notalways assigned new values. It is necessary to check for null beforedereferencing.This fixes 2 FORWARD_NULL issues reported by Coverity.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hwThis commit addresses a potential null pointer dereference issue in the`dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` isnull.The fix adds a check to ensure `dc->clk_mgr` is not null beforeaccessing its functions. This prevents a potential null pointerdereference.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Fix possible crash on mgmt_index_removedIf mgmt_index_removed is called while there are commands queued oncmd_sync it could lead to crashes like the bellow trace:0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth]0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth]0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth]So while handling mgmt_index_removed this attempts to dequeuecommands passed as user_data to cmd_sync.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gso: fix udp gso fraglist segmentation after pull from frag_listDetect gso fraglist skbs with corrupted geometry (see below) andpass these to skb_segment instead of skb_segment_list, as the firstcan segment them correctly.Valid SKB_GSO_FRAGLIST skbs- consist of two or more segments- the head_skb holds the protocol headers plus first gso_size- one or more frag_list skbs hold exactly one segment- all but the last must be gso_sizeOptional datapath hooks such as NAT and BPF (bpf_skb_pull_data) canmodify these skbs, breaking these invariants.In extreme cases they pull all data into skb linear. For UDP, thiscauses a NULL ptr deref in __udpv4_gso_segment_list_csum atudp_hdr(seg->next)->dest.Detect invalid geometry due to pull, by checking head_skb size.Don't just drop, as this may blackhole a destination. Convert to beable to pass to regular skb_segment.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: fix integer overflow in BLKSECDISCARDI independently rediscovered commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 block: fix overflow in blk_ioctl_discard()but for secure erase.Same problem: uint64_t r[2] = {512, 18446744073709551104ULL}; ioctl(fd, BLKSECDISCARD, r);will enter near infinite loop inside blkdev_issue_secure_erase(): a.out: attempt to access beyond end of device loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 bio_check_eod: 3286214 callbacks suppressed
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: improve shutdown sequenceAlexander Sverdlin presents 2 problems during shutdown with thelan9303 driver. One is specific to lan9303 and the other just happensto reproduce there.The first problem is that lan9303 is unique among DSA drivers in that itcalls dev_get_drvdata() at "arbitrary runtime" (not probe, not shutdown,not remove):phy_state_machine()-> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata()But we never stop the phy_state_machine(), so it may continue to runafter dsa_switch_shutdown(). Our common pattern in all DSA drivers isto set drvdata to NULL to suppress the remove() method that may comeafterwards. But in this case it will result in an NPD.The second problem is that the way in which we setdp->conduit->dsa_ptr = NULL; is concurrent with receive packetprocessing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL,but afterwards, rather than continuing to use that non-NULL value,dev->dsa_ptr is dereferenced again and again without NULL checks:dsa_conduit_find_user() and many other places. In between dereferences,there is no locking to ensure that what was valid once continues to bevalid.Both problems have the common aspect that closing the conduit interfacesolves them.In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWNevent in dsa_user_netdevice_event() which closes user ports as well.dsa_port_disable_rt() calls phylink_stop(), which synchronously stopsthe phylink state machine, and ds->ops->phy_read() will thus no longercall into the driver after this point.In the second case, dev_close(conduit) should do this, as perDocumentation/networking/driver.rst:| Quiescence| ----------|| After the ndo_stop routine has been called, the hardware must| not receive or transmit any data. All in flight packets must| be aborted. If necessary, poll or wait for completion of| any reset commands.So it should be sufficient to ensure that later, when we zeroizeconduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() callon this conduit.The addition of the netif_device_detach() function is to ensure thatioctls, rtnetlinks and ethtool requests on the user ports no longerpropagate down to the driver - we're no longer prepared to handle them.The race condition actually did not exist when commit 0650bf52b31f("net: dsa: be compatible with masters which unregister on shutdown")first introduced dsa_switch_shutdown(). It was created later, when westopped unregistering the user interfaces from a bad spot, and we justreplaced that sequence with a racy zeroization of conduit->dsa_ptr(one which doesn't ensure that the interfaces aren't up).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: dax: fix overflowing extents beyond inode size when partially writingThe dax_iomap_rw() does two things in each iteration: map written blocksand copy user data to blocks. If the process is killed by user(See signalhandling in dax_iomap_iter()), the copied data will be returned and addedon inode size, which means that the length of written extents may exceedthe inode size, then fsck will fail. An example is given as:dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2Mfsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix?Fix the problem by truncating extents if the written length is smallerthan expected.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xtables: avoid NFPROTO_UNSPEC where neededsyzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packetprocessing. As this is only useful to restrict locally terminatingTCP/UDP traffic, register this for ipv4 and ipv6 family only.Pablo points out that this is a general issue, direct users of theset/getsockopt interface can call into targets/matches that were onlyintended for use with ip(6)tables.Check all UNSPEC matches and targets for similar issues:- matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area.- targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE.Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, asthey are provided for use by ip(6)tables.The MARK target is also used by arptables, so register for NFPROTO_ARP too.While at it, bail out if connbytes fails to enable the correspondingconntrack family.This change passes the selftests in iptables.git.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: accept TCA_STAB only for root qdiscMost qdiscs maintain their backlog using qdisc_pkt_len(skb)on the assumption it is invariant between the enqueue()and dequeue() handlers.Unfortunately syzbot can crash a host rather easily usinga TBF + SFQ combination, with an STAB on SFQ [1]We can't support TCA_STAB on arbitrary level, this wouldrequire to maintain per-qdisc storage.[1][ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 88.798611] #PF: supervisor read access in kernel mode[ 88.799014] #PF: error_code(0x0000) - not-present page[ 88.799506] PGD 0 P4D 0[ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI[ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117[ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq[ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00All code======== 0: 0f b7 50 12 movzwl 0x12(%rax),%edx 4: 48 8d 04 d5 00 00 00 lea 0x0(,%rdx,8),%rax b: 00 c: 48 89 d6 mov %rdx,%rsi f: 48 29 d0 sub %rdx,%rax 12: 48 8b 91 c0 01 00 00 mov 0x1c0(%rcx),%rdx 19: 48 c1 e0 03 shl $0x3,%rax 1d: 48 01 c2 add %rax,%rdx 20: 66 83 7a 1a 00 cmpw $0x0,0x1a(%rdx) 25: 7e c0 jle 0xffffffffffffffe7 27: 48 8b 3a mov (%rdx),%rdi 2a:* 4c 8b 07 mov (%rdi),%r8 <-- trapping instruction 2d: 4c 89 02 mov %r8,(%rdx) 30: 49 89 50 08 mov %rdx,0x8(%r8) 34: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 3b: 00 3c: 48 rex.W 3d: c7 .byte 0xc7 3e: 07 (bad) ...Code starting with the faulting instruction=========================================== 0: 4c 8b 07 mov (%rdi),%r8 3: 4c 89 02 mov %r8,(%rdx) 6: 49 89 50 08 mov %rdx,0x8(%r8) a: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 11: 00 12: 48 rex.W 13: c7 .byte 0xc7 14: 07 (bad) ...[ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206[ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800[ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000[ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f[ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140[ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac[ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000[ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0[ 88.808165] Call Trace:[ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)[ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715)[ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539)[ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)[ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq[ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq[ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix race between laundromat and free_stateidThere is a race between laundromat handling of revoked delegationsand a client sending free_stateid operation. Laundromat threadfinds that delegation has expired and needs to be revoked so itmarks the delegation stid revoked and it puts it on a reaper listbut then it unlock the state lock and the actual delegation revocationhappens without the lock. Once the stid is marked revoked a racingfree_stateid processing thread does the following (1) it callslist_del_init() which removes it from the reaper list and (2) freesthe delegation stid structure. The laundromat thread ends up notcalling the revoke_delegation() function for this particular delegationbut that means it will no release the lock lease that exists onthe file.Now, a new open for this file comes in and ends up finding thatlease list isn't empty and calls nfsd_breaker_owns_lease() which endsup trying to derefence a freed delegation stateid. Leading to thefollowint use-after-free KASAN warning:kernel: ==================================================================kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd]kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205kernel:kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024kernel: Call trace:kernel: dump_backtrace+0x98/0x120kernel: show_stack+0x1c/0x30kernel: dump_stack_lvl+0x80/0xe8kernel: print_address_description.constprop.0+0x84/0x390kernel: print_report+0xa4/0x268kernel: kasan_report+0xb4/0xf8kernel: __asan_report_load8_noabort+0x1c/0x28kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd]kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd]kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd]kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd]kernel: nfsd4_process_open2+0xa40/0x1a40 [nfsd]kernel: nfsd4_open+0xa08/0xe80 [nfsd]kernel: nfsd4_proc_compound+0xb8c/0x2130 [nfsd]kernel: nfsd_dispatch+0x22c/0x718 [nfsd]kernel: svc_process_common+0x8e8/0x1960 [sunrpc]kernel: svc_process+0x3d4/0x7e0 [sunrpc]kernel: svc_handle_xprt+0x828/0xe10 [sunrpc]kernel: svc_recv+0x2cc/0x6a8 [sunrpc]kernel: nfsd+0x270/0x400 [nfsd]kernel: kthread+0x288/0x310kernel: ret_from_fork+0x10/0x20This patch proposes a fixed that's based on adding 2 new additionalstid's sc_status values that help coordinate between the laundromatand other operations (nfsd4_free_stateid() and nfsd4_delegreturn()).First to make sure, that once the stid is marked revoked, it is notremoved by the nfsd4_free_stateid(), the laundromat take a referenceon the stateid. Then, coordinating whether the stid has been puton the cl_revoked list or we are processing FREE_STATEID and need tomake sure to remove it from the list, each check that state and actaccordingly. If laundromat has added to the cl_revoke list beforethe arrival of FREE_STATEID, then nfsd4_free_stateid() knows to removeit from the list. If nfsd4_free_stateid() finds that operations arrivedbefore laundromat has placed it on cl_revoke list, it marks the statefreed and then laundromat will no longer add it to the list.Also, for nfsd4_delegreturn() when looking for the specified stid,we need to access stid that are marked removed or freeable, it meansthe laundromat has started processing it but hasn't finished and thisdelegreturn needs to return nfserr_deleg_revoked and notnfserr_bad_stateid. The latter will not trigger a FREE_STATEID and thelack of it will leave this stid on the cl_revoked list indefinitely.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix OOBs when building SMB2_IOCTL requestWhen using encryption, either enforced by the server or when using'seal' mount option, the client will squash all compound request buffersdown for encryption into a single iov in smb2_set_next_command().SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold theSMB2_IOCTL request in the first iov, and if the user passes an inputbuffer that is greater than 328 bytes, smb2_set_next_command() willend up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e "print('a')for 1..1024") /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_report+0xda/0x110 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_check_range+0x10f/0x1f0 __asan_memcpy+0x3c/0x60 smb2_set_next_command.cold+0x1d6/0x24c [cifs] smb2_compound_op+0x238c/0x3840 [cifs] ? kasan_save_track+0x14/0x30 ? kasan_save_free_info+0x3b/0x70 ? vfs_symlink+0x1a1/0x2c0 ? do_symlinkat+0x108/0x1c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? smb2_create_reparse_symlink+0x38f/0x490 [cifs] smb2_create_reparse_symlink+0x38f/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs] cifs_symlink+0x24f/0x960 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? generic_permission+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fsl/fman: Fix refcount handling of fman-related devicesIn mac_probe() there are multiple calls to of_find_device_by_node(),fman_bind() and fman_port_bind() which takes references to of_dev->dev.Not all references taken by these calls are released later on error pathin mac_probe() and in mac_remove() which lead to reference leaks.Add references release.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: handle consistently DSS corruptionBugged peer implementation can send corrupted DSS options, consistentlyhitting a few warning in the data path. Use DEBUG_NET assertions, toavoid the splat on some builds and handle consistently the error, dumpingrelated MIBs and performing fallback and/or reset according to thesubflow type.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/swapfile: skip HugeTLB pages for unuse_vmaI got a bad pud error and lost a 1GB HugeTLB when calling swapoff. Theproblem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7)We can tell that pud_clear_bad is called by pud_none_or_clear_bad inunuse_pud_range() by ftrace. And therefore the HugeTLB pages will neverbe freed because we lost it from page table. We can skip HugeTLB pagesfor unuse_vma to fix it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: propagate directory read errors from nilfs_find_entry()Syzbot reported that a task hang occurs in vcs_open() during a fuzzingtest for nilfs2.The root cause of this problem is that in nilfs_find_entry(), whichsearches for directory entries, ignores errors when loading a directorypage/folio via nilfs_get_folio() fails.If the filesystem images is corrupted, and the i_size of the directoryinode is large, and the directory page/folio is successfully read butfails the sanity check, for example when it is zero-filled,nilfs_check_folio() may continue to spit out error messages in bursts.Fix this issue by propagating the error to the callers when loading apage/folio fails in nilfs_find_entry().The current interface of nilfs_find_entry() and its callers is outdatedand cannot propagate error codes such as -EIO and -ENOMEM returned vianilfs_find_entry(), so fix it together.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_payload: sanitize offset and length before calling skb_checksum()If access to offset + length is larger than the skbuff length, thenskb_checksum() triggers BUG_ON().skb_checksum() internally subtracts the length parameter while iteratingover skbuff, BUG_ON(len) at the end of it checks that the expectedlength to be included in the checksum calculation is fully consumed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()I got a syzbot report without a repro [1] crashing in nf_send_reset6()I think the issue is that dev->hard_header_len is zero, and we attemptlater to push an Ethernet header.Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.[1]skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 !Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3RSP: 0018:ffffc900045269b0 EFLAGS: 00010282RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4cccR10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003cFS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fdbeeb7d1ffCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ffRDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8RBP: 00007fdbeebf12be R08: 0000000---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix crash when config small gso_max_size/gso_ipv4_max_sizeConfig a small gso_max_size/gso_ipv4_max_size will lead to an underflowin sk_dst_gso_max_size(), which may trigger a BUG_ON crash,because sk->sk_gso_max_size would be much bigger than device limits.Call Trace:tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs)Add check for the minimum value of gso_max_size and gso_ipv4_max_size.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:filemap: Fix bounds checking in filemap_read()If the caller supplies an iocb->ki_pos value that is close to thefilesystem upper limit, and an iterator with a count that causes us tooverflow that limit, then filemap_read() enters an infinite loop.This behaviour was discovered when testing xfstests generic/525 with the"localio" optimisation for loopback NFS mounts.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash when uninstalling driverWhen the driver is uninstalled and the VF is disabled concurrently, akernel crash occurs. The reason is that the two actions call functionpci_disable_sriov(). The num_VFs is checked to determine whether torelease the corresponding resources. During the second calling, num_VFsis not 0 and the resource release function is called. However, thecorresponding resource has been released during the first invoking.Therefore, the problem occurs:[15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020...[15278.131557][T50670] Call trace:[15278.134686][T50670] klist_put+0x28/0x12c[15278.138682][T50670] klist_del+0x14/0x20[15278.142592][T50670] device_del+0xbc/0x3c0[15278.146676][T50670] pci_remove_bus_device+0x84/0x120[15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80[15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c[15278.162485][T50670] sriov_disable+0x50/0x11c[15278.166829][T50670] pci_disable_sriov+0x24/0x30[15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3][15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge][15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230[15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30[15278.193848][T50670] invoke_syscall+0x50/0x11c[15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164[15278.203837][T50670] do_el0_svc+0x34/0xcc[15278.207834][T50670] el0_svc+0x20/0x30For details, see the following figure. rmmod hclge disable VFs----------------------------------------------------hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock();In this patch, when driver is removing, we get the device_lock()to protect num_VFs, just like sriov_numvfs_store().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()The per-netns IP tunnel hash table is protected by the RTNL mutex andip_tunnel_find() is only called from the control path where the mutex istaken.Add a lockdep expression to hlist_for_each_entry_rcu() inip_tunnel_find() in order to validate that the mutex is held and tosilence the suspicious RCU usage warning [1].[1]WARNING: suspicious RCU usage6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted-----------------------------net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 11 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60stack backtrace:CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igb: Fix potential invalid memory access in igb_init_module()The pci_register_driver() can fail and when this happened, the dca_notifierneeds to be unregistered, otherwise the dca_notifier can be called whenigb fails to install, resulting to invalid memory access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: zynqmp_dp: Fix integer overflow in zynqmp_dp_rate_get()This patch fixes a potential integer overflow in the zynqmp_dp_rate_get()The issue comes up when the expressiondrm_dp_bw_code_to_link_rate(dp->test.bw_code) * 10000 is evaluated using 32-bitNow the constant is a compatible 64-bit type.Resolves coverity issues: CID 1636340 and CID 1635811
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit()The "submit->cmd[i].size" and "submit->cmd[i].offset" variables are u32values that come from the user via the submit_lookup_cmds() function.This addition could lead to an integer wrapping bug so use size_add()to prevent that.Patchwork: https://patchwork.freedesktop.org/patch/624696/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/hdcp: Add encoder check in intel_hdcp_get_capabilitySometimes during hotplug scenario or suspend/resume scenario encoder isnot always initialized when intel_hdcp_get_capability adda check to avoid kernel null pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: fix 6 GHz scan constructionIf more than 255 colocated APs exist for the set of allAPs found during 2.4/5 GHz scanning, then the 6 GHz scanconstruction will loop forever since the loop variablehas type u8, which can never reach the number found whenthat's bigger than 255, and is stored in a u32 variable.Also move it into the loops to have a smaller scope.Using a u32 there is fine, we limit the number of APs inthe scan list and each has a limit on the number of RNRentries due to the frame size. With a limit of 1000 scanresults, a frame size upper bound of 4096 (really it'smore like ~2300) and a TBTT entry size of at least 11,we get an upper bound for the number of ~372k, well inthe bounds of a u32.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()In mtk_crtc_create(), if the call to mbox_request_channel() fails then weset the "mtk_crtc->cmdq_client.chan" pointer to NULL. In that situation,we do not call cmdq_pkt_create().During the cleanup, we need to check if the "mtk_crtc->cmdq_client.chan"is NULL first before calling cmdq_pkt_destroy(). Callingcmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() andit will result in a NULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86/amd/pmc: Detect when STB is not availableLoading the amd_pmc module as: amd_pmc enable_stb=1...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340Further debugging reveals that this occurs when the requests forS2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0,indicating that the STB is inaccessible. To prevent the ioremapwarning and provide clarity to the user, handle the invalid addressand display an error message.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:afs: Fix lock recursionafs_wake_up_async_call() can incur lock recursion. The problem is that itis called from AF_RXRPC whilst holding the ->notify_lock, but it tries totake a ref on the afs_call struct in order to pass it to a work queue - butif the afs_call is already queued, we then have an extraneous ref that mustbe put... calling afs_put_call() may call back down into AF_RXRPC throughrxrpc_kernel_shutdown_call(), however, which might try taking the->notify_lock again.This case isn't very common, however, so defer it to a workqueue. The oopslooks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-multipath: defer partition scanningWe need to suppress the partition scan from occuring within thecontroller's scan_work context. If a path error occurs here, the IO willwait until a path becomes available or all paths are torn down, but thataction also occurs within scan_work, so it would deadlock. Defer thepartion scan to a different context that does not block scan_work.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Fix use-after-free of network namespace.Recently, we got a customer report that CIFS triggers oops whilereconnecting to a server. [0]The workload runs on Kubernetes, and some pods mount CIFS serversin non-root network namespaces. The problem rarely happened, butit was always while the pod was dying.The root cause is wrong reference counting for network namespace.CIFS uses kernel sockets, which do not hold refcnt of the netns thatthe socket belongs to. That means CIFS must ensure the socket isalways freed before its netns; otherwise, use-after-free happens.The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFSWe can reproduce the issue quickly with the script [1] below and seethe splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled.When the socket is TCP, it is hard to guarantee the netns lifetimewithout holding refcnt due to async timers.Let's hold netns refcnt for each socket as done for SMC in commit9744d2bf1976 ("smc: Fix use-after-free in tcp_write_timer_handler().").Note that we need to move put_net() from cifs_put_tcp_session() toclean_demultiplex_info(); otherwise, __sock_create() still could touch afreed netns while cifsd tries to reconnect from cifs_demultiplex_thread().Also, maybe_get_net() cannot be put just before __sock_create() becausethe code is not under RCU and there is a small chance that the sameaddress happened to be reallocated to another netns.[0]:CIFS: VFS: \\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting...CIFS: Serverclose failed 4 times, giving upUnable to handle kernel paging request at virtual address 14de99e461f84a07Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation faultData abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0[14de99e461f84a07] address between user and kernel address rangesInternal error: Oops: 0000000096000004 [#1] SMPModules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfsCPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : fib_rules_lookup+0x44/0x238lr : __fib_lookup+0x64/0xbcsp : ffff8000265db790x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointerWhen hvs is released, there is a possibility that vsk->trans may notbe initialized to NULL, which could lead to a dangling pointer.This issue is resolved by initializing vsk->trans to NULL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: uncache inode which has failed entering the groupSyzbot has reported the following BUG:kernel BUG at fs/ocfs2/uptodate.c:509!...Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particularinode in 'ocfs2_verify_group_and_input()', corresponding buffer headremains cached and subsequent call to the same 'ioctl()' for the sameinode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (tryingto cache the same buffer head of that inode). Fix this by uncachingthe buffer head with 'ocfs2_remove_from_cache()' on error path in'ocfs2_group_add()'.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: fix NULL pointer dereference in alloc_pages_bulk_noprofWe triggered a NULL pointer dereference for ac.preferred_zoneref->zone inalloc_pages_bulk_noprof() when the task is migrated between cpusets.When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be¤t->mems_allowed. when first_zones_zonelist() is called to findpreferred_zoneref, the ac->nodemask may be modified concurrently if thetask is migrated between different cpusets. Assuming we have 2 NUMA Node,when traversing Node1 in ac->zonelist, the nodemask is 2, and whentraversing Node2 in ac->zonelist, the nodemask is 1. As a result, theac->preferred_zoneref points to NULL zone.In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds aallowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leadingto NULL pointer dereference.__alloc_pages_noprof() fixes this issue by checking NULL pointer in commitea57485af8f4 ("mm, page_alloc: fix check for NULL preferred_zone") andcommit df76cee6bbeb ("mm, page_alloc: remove redundant checks from allocfastpath").To fix it, check NULL pointer for preferred_zoneref->zone.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio/vsock: Fix accept_queue memory leakAs the final stages of socket destruction may be delayed, it is possiblethat virtio_transport_recv_listen() will be called after the accept_queuehas been flushed, but before the SOCK_DONE flag has been set. As a result,sockets enqueued after the flush would remain unremoved, leading to amemory leak.vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK(!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) releaseclose_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound releaseIntroduce a sk_shutdown check to disallow vsock_enqueue_accept() duringsocket destruction.unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: CT: Fix null-ptr-deref in add rule err flowIn error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add()callback returns error, zone_rule->attr is used uninitiated. Fix it touse attr which has the needed pointer value.Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core]... Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: fs, lock FTE when checking if activeThe referenced commits introduced a two-step process for deleting FTEs:- Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE.- Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray.However, this approach encounters a race condition if a rule with the samematch value is added simultaneously. In this scenario, fs_core may set thehardware deletion function to NULL prematurely, causing a panic duringsubsequent rule deletions.To prevent this, ensure the active flag of the FTE is checked under a lock,which will prevent the fs_core layer from attaching a new steering rule toan FTE that is in the process of deletion.[ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func[ 438.968205] ------------[ cut here ]------------[ 438.968654] refcount_t: decrement hit 0; leaking memory.[ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110[ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower][ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8[ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014[ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110[ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90[ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286[ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000[ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0[ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0[ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0[ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0[ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000[ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0[ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 438.986507] Call Trace:[ 438.986799] [ 438.987070] ? __warn+0x7d/0x110[ 438.987426] ? refcount_warn_saturate+0xfb/0x110[ 438.987877] ? report_bug+0x17d/0x190[ 438.988261] ? prb_read_valid+0x17/0x20[ 438.988659] ? handle_bug+0x53/0x90[ 438.989054] ? exc_invalid_op+0x14/0x70[ 438.989458] ? asm_exc_invalid_op+0x16/0x20[ 438.989883] ? refcount_warn_saturate+0xfb/0x110[ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core][ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core][ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core][ 438.992054] ? xas_load+0x9/0xb0[ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core][ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core][ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core][ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core][ 438.994728] tc_setup_cb_destroy+0xb9/0x190[ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower][ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower][ 438.996105] tc_new_tfilter+0x347/0xbc0[ 438.996503] ? __---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: cope racing subflow creation in mptcp_rcv_space_adjustAdditional active subflows - i.e. created by the in kernel pathmanager - are included into the subflow list before starting the3whs.A racing recvmsg() spooling data received on an already establishedsubflow would unconditionally call tcp_cleanup_rbuf() on all thecurrent subflows, potentially hitting a divide by zero error onthe newly created ones.Explicitly check that the subflow is in a suitable state beforeinvoking tcp_cleanup_rbuf().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix data-races around sk->sk_forward_allocSyzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]---Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add()concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked,which triggers a data-race around sk->sk_forward_alloc:tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add()In this syzkaller testcase, two threads calltcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes likethis: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() whensk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock().Fix the same issue in dccp_v6_do_rcv().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix null-ptr-deref in block_dirty_buffer tracepointWhen using the "block:block_dirty_buffer" tracepoint, mark_buffer_dirty()may cause a NULL pointer dereference, or a general protection fault whenKASAN is enabled.This happens because, since the tracepoint was added inmark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_devregardless of whether the buffer head has a pointer to a block_devicestructure.In the current implementation, nilfs_grab_buffer(), which grabs a bufferto read (or create) a block of metadata, including b-tree node blocks,does not set the block device, but instead does so only if the buffer isnot in the "uptodate" state for each of its caller block readingfunctions. However, if the uptodate flag is set on a folio/page, and thebuffer heads are detached from it by try_to_free_buffers(), and new bufferheads are then attached by create_empty_buffers(), the uptodate flag maybe restored to each buffer without the block device being set tobh->b_bdev, and mark_buffer_dirty() may be called later in that state,resulting in the bug mentioned above.Fix this issue by making nilfs_grab_buffer() always set the block deviceof the super block structure to the buffer head, regardless of the stateof the buffer's uptodate flag.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix null-ptr-deref in block_touch_buffer tracepointPatch series "nilfs2: fix null-ptr-deref bugs on block tracepoints".This series fixes null pointer dereference bugs that occur when usingnilfs2 and two block-related tracepoints.This patch (of 2):It has been reported that when using "block:block_touch_buffer"tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes aNULL pointer dereference, or a general protection fault when KASAN isenabled.This happens because since the tracepoint was added in touch_buffer(), itreferences the dev_t member bh->b_bdev->bd_dev regardless of whether thebuffer head has a pointer to a block_device structure. In the currentimplementation, the block_device structure is set after the functionreturns to the caller.Here, touch_buffer() is used to mark the folio/page that owns the bufferhead as accessed, but the common search helper for folio/page used by thecaller function was optimized to mark the folio/page as accessed when itwas reimplemented a long time ago, eliminating the need to calltouch_buffer() here in the first place.So this solves the issue by eliminating the touch_buffer() call itself.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKENHide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable supportfor virtualizing Intel PT via guest/host mode unless BROKEN=y. There aremyriad bugs in the implementation, some of which are fatal to the guest,and others which put the stability and health of the host at risk.For guest fatalities, the most glaring issue is that KVM fails to ensuretracing is disabled, and *stays* disabled prior to VM-Enter, which isnecessary as hardware disallows loading (the guest's) RTIT_CTL if tracingis enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the "load IA32_RTIT_CTL" VM-entry control must be 0.On the host side, KVM doesn't validate the guest CPUID configurationprovided by userspace, and even worse, uses the guest configuration todecide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuringguest CPUID to enumerate more address ranges than are supported in hardwarewill result in KVM trying to passthrough, save, and load non-existent MSRs,which generates a variety of WARNs, ToPA ERRORs in the host, a potentialdeadlock, etc.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: terminate outstanding dump on socket closeNetlink supports iterative dumping of data. It provides the familiesthe following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanupThe whole process is asynchronous and the repeated calls to .dumpdon't actually happen in a tight loop, but rather are triggeredin response to recvmsg() on the socket.This gives the user full control over the dump, but also means thatthe user can close the socket without getting to the end of the dump.To make sure .start is always paired with .done we check if thereis an ongoing dump before freeing the socket, and if so call .done.The complication is that sockets can get freed from BH and .doneis allowed to sleep. So we use a workqueue to defer the call, whenneeded.Unfortunately this does not work correctly. What we defer is notthe cleanup but rather releasing a reference on the socket.We have no guarantee that we own the last reference, if someoneelse holds the socket they may release it in BH and we're backto square one.The whole dance, however, appears to be unnecessary. Only the usercan interact with dumps, so we can clean up when socket is closed.And close always happens in process context. Some async code maystill access the socket after close, queue notification skbs to it etc.but no dumps can start, end or otherwise make progress.Delete the workqueue and flush the dump state directly from the releasehandler. Note that further cleanup is possible in -next, for instancewe now always call .done before releasing the main module reference,so dump doesn't have to take a reference of its own.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scpi: Check the DVFS OPP count returned by the firmwareFix a kernel crash with the below call trace when the SCPI firmwarereturns OPP count of zero.dvfs_info.opp_count may be zero on some platforms during the reboottest, and the kernel will crash after dereferencing the pointer tokcalloc(info->count, sizeof(*opp), GFP_KERNEL). | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 | Mem abort info: | ESR = 0x96000004 | Exception class = DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info: | ISV = 0, ISS = 0x00000004 | CM = 0, WnR = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c | [0000000000000028] pgd=0000000000000000 | Internal error: Oops: 96000004 [#1] SMP | scpi-hwmon: probe of PHYT000D:00 failed with error -110 | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c) | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1 | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | lr : clk_register+0x438/0x720 | Call trace: | scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | devm_clk_hw_register+0x50/0xa0 | scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi] | scpi_clocks_probe+0x528/0x70c [clk_scpi] | platform_drv_probe+0x58/0xa8 | really_probe+0x260/0x3d0 | driver_probe_device+0x12c/0x148 | device_driver_attach+0x74/0x98 | __driver_attach+0xb4/0xe8 | bus_for_each_dev+0x88/0xe0 | driver_attach+0x30/0x40 | bus_add_driver+0x178/0x2b0 | driver_register+0x64/0x118 | __platform_driver_register+0x54/0x60 | scpi_clocks_driver_init+0x24/0x1000 [clk_scpi] | do_one_initcall+0x54/0x220 | do_init_module+0x54/0x1c8 | load_module+0x14a4/0x1668 | __se_sys_finit_module+0xf8/0x110 | __arm64_sys_finit_module+0x24/0x30 | el0_svc_common+0x78/0x170 | el0_svc_handler+0x38/0x78 | el0_svc+0x8/0x340 | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820) | ---[ end trace 06feb22469d89fa8 ]--- | Kernel panic - not syncing: Fatal exception | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x10,a0002008 | Memory Limit: none
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubi: fastmap: Fix duplicate slab cache names while attachingSince commit 4c39529663b9 ("slab: Warn on duplicate cache names whenDEBUG_VM=y"), the duplicate slab cache names can be detected and akernel WARNING is thrown out.In UBI fast attaching process, alloc_ai() could be invoked twicewith the same slab cache name 'ubi_aeb_slab_cache', which will triggerfollowing warning messages: kmem_cache of name 'ubi_aeb_slab_cache' already exists WARNING: CPU: 0 PID: 7519 at mm/slab_common.c:107 __kmem_cache_create_args+0x100/0x5f0 Modules linked in: ubi(+) nandsim [last unloaded: nandsim] CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2 RIP: 0010:__kmem_cache_create_args+0x100/0x5f0 Call Trace: __kmem_cache_create_args+0x100/0x5f0 alloc_ai+0x295/0x3f0 [ubi] ubi_attach+0x3c3/0xcc0 [ubi] ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi] ubi_init+0x3fb/0x800 [ubi] do_init_module+0x265/0x7d0 __x64_sys_finit_module+0x7a/0xc0The problem could be easily reproduced by loading UBI device by fastmapwith CONFIG_DEBUG_VM=y.Fix it by using different slab names for alloc_ai() callers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: make sure cache entry active before cache_showThe function `c_show` was called with protection from RCU. This onlyensures that `cp` will not be freed. Therefore, the reference count for`cp` can drop to zero, which will trigger a refcount use-after-freewarning when `cache_get` is called. To resolve this issue, use`cache_get_rcu` to ensure that `cp` remains active.------------[ cut here ]------------refcount_t: addition on 0; use-after-free.WARNING: CPU: 7 PID: 822 at lib/refcount.c:25refcount_warn_saturate+0xb1/0x120CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014RIP: 0010:refcount_warn_saturate+0xb1/0x120Call Trace: c_show+0x2fc/0x380 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: Add sanity NULL check for the default mmap fault handlerA driver might allow the mmap access before initializing itsruntime->dma_area properly. Add a proper NULL check before passing tovirt_to_page() for avoiding a panic.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix NULL ptr deref in crypto_aead_setkey()Neither SMB3.0 or SMB3.02 supports encryption negotiate context, sowhen SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response,the client uses AES-128-CCM as the default cipher. See MS-SMB23.3.5.4.Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") addeda @server->cipher_type check to conditionally callsmb3_crypto_aead_allocate(), but that check would always be false as@server->cipher_type is unset for SMB3.02.Fix the following KASAN splat by setting @server->cipher_type forSMB3.02 as well.mount.cifs //srv/share /mnt -o vers=3.02,seal,...BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130Read of size 8 at addr 0000000000000020 by task mount.cifs/1095CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc4104/01/2014Call Trace: dump_stack_lvl+0x5d/0x80 ? crypto_aead_setkey+0x2c/0x130 kasan_report+0xda/0x110 ? crypto_aead_setkey+0x2c/0x130 crypto_aead_setkey+0x2c/0x130 crypt_message+0x258/0xec0 [cifs] ? __asan_memset+0x23/0x50 ? __pfx_crypt_message+0x10/0x10 [cifs] ? mark_lock+0xb0/0x6a0 ? hlock_class+0x32/0xb0 ? mark_lock+0xb0/0x6a0 smb3_init_transform_rq+0x352/0x3f0 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 smb_send_rqst+0x144/0x230 [cifs] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] ? hlock_class+0x32/0xb0 ? smb2_setup_request+0x225/0x3a0 [cifs] ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs] compound_send_recv+0x59b/0x1140 [cifs] ? __pfx_compound_send_recv+0x10/0x10 [cifs] ? __create_object+0x5e/0x90 ? hlock_class+0x32/0xb0 ? do_raw_spin_unlock+0x9a/0xf0 cifs_send_recv+0x23/0x30 [cifs] SMB2_tcon+0x3ec/0xb30 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? __pfx_lock_release+0x10/0x10 ? do_raw_spin_trylock+0xc6/0x120 ? lock_acquire+0x3f/0x90 ? _get_xid+0x16/0xd0 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs] cifs_get_smb_ses+0xcdd/0x10a0 [cifs] ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs] ? cifs_get_tcp_session+0xaa0/0xca0 [cifs] cifs_mount_get_session+0x8a/0x210 [cifs] dfs_mount_share+0x1b0/0x11d0 [cifs] ? __pfx___lock_acquire+0x10/0x10 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? lock_release+0x203/0x5d0 cifs_mount+0xb3/0x3d0 [cifs] ? do_raw_spin_trylock+0xc6/0x120 ? __pfx_cifs_mount+0x10/0x10 [cifs] ? lock_acquire+0x3f/0x90 ? find_nls+0x16/0xa0 ? smb3_update_mnt_flags+0x372/0x3b0 [cifs] cifs_smb3_do_mount+0x1e2/0xc80 [cifs] ? __pfx_vfs_parse_fs_string+0x10/0x10 ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs] smb3_get_tree+0x1bf/0x330 [cifs] vfs_get_tree+0x4a/0x160 path_mount+0x3c1/0xfb0 ? kasan_quarantine_put+0xc7/0x1d0 ? __pfx_path_mount+0x10/0x10 ? kmem_cache_free+0x118/0x3e0 ? user_path_at+0x74/0xa0 __x64_sys_mount+0x1a6/0x1e0 ? __pfx___x64_sys_mount+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx->plane_state in dcn20_program_pipeThis commit addresses a null pointer dereference issue indcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ("drm/amd/display:Add null check for pipe_ctx->plane_state in dcn20_program_pipe")partially fixed the null pointer dereference issue. However, indcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, andplane_state is accessed again through pipe_ctx. Multiple if statementsdirectly call attributes of plane_state, leading to potential nullpointer dereference issues. This patch adds necessary null checks toensure stability.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount(skb->users) and iucv_sock_recvmsg() does not decrement skb refcountat exit.This results in skb memory leak in skb_queue_purge() and WARN_ON iniucv_sock_destruct() during socket close. To fix this decreaseskb refcount by one if MSG_PEEK is set in order to prevent memoryleak and WARN_ON.WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv]CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1Hardware name: IBM 3931 A01 704 (z/VM 7.3.0)Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtiofs: use pages instead of pointer for kernel direct IOWhen trying to insert a 10MB kernel module kept in a virtio-fs with cachedisabled, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ...... Modules linked in: CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:__alloc_pages+0x2bf/0x380 ...... Call Trace: ? __warn+0x8e/0x150 ? __alloc_pages+0x2bf/0x380 __kmalloc_large_node+0x86/0x160 __kmalloc+0x33c/0x480 virtio_fs_enqueue_req+0x240/0x6d0 virtio_fs_wake_pending_and_unlock+0x7f/0x190 queue_request_and_unlock+0x55/0x60 fuse_simple_request+0x152/0x2b0 fuse_direct_io+0x5d2/0x8c0 fuse_file_read_iter+0x121/0x160 __kernel_read+0x151/0x2d0 kernel_read+0x45/0x50 kernel_read_file+0x1a9/0x2a0 init_module_from_file+0x6a/0xe0 idempotent_init_module+0x175/0x230 __x64_sys_finit_module+0x5d/0xb0 x64_sys_call+0x1c3/0x9e0 do_syscall_64+0x3d/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ...... ---[ end trace 0000000000000000 ]---The warning is triggered as follows:1) syscall finit_module() handles the module insertion and it invokeskernel_read_file() to read the content of the module first.2) kernel_read_file() allocates a 10MB buffer by using vmalloc() andpasses it to kernel_read(). kernel_read() constructs a kvec iter byusing iov_iter_kvec() and passes it to fuse_file_read_iter().3) virtio-fs disables the cache, so fuse_file_read_iter() invokesfuse_direct_io(). As for now, the maximal read size for kvec iter isonly limited by fc->max_read. For virtio-fs, max_read is UINT_MAX, sofuse_direct_io() doesn't split the 10MB buffer. It saves the address andthe size of the 10MB-sized buffer in out_args[0] of a fuse request andpasses the fuse request to virtio_fs_wake_pending_and_unlock().4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() toqueue the request. Because virtiofs need DMA-able address, sovirtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer forall fuse args, copies these args into the bounce buffer and passed thephysical address of the bounce buffer to virtiofsd. The total length ofthese fuse args for the passed fuse request is about 10MB, socopy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter andit triggers the warning in __alloc_pages(): if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)) return NULL;5) virtio_fs_enqueue_req() will retry the memory allocation in akworker, but it won't help, because kmalloc() will always return NULLdue to the abnormal size and finit_module() will hang forever.A feasible solution is to limit the value of max_read for virtio-fs, sothe length passed to kmalloc() will be limited. However it will affectthe maximal read size for normal read. And for virtio-fs write initiatedfrom kernel, it has the similar problem but now there is no way to limitfc->max_write in kernel.So instead of limiting both the values of max_read and max_write inkernel, introducing use_pages_for_kvec_io in fuse_conn and setting it astrue in virtiofs. When use_pages_for_kvec_io is enabled, fuse will usepages instead of pointer to pass the KVEC_IO data.After switching to pages for KVEC_IO data, these pages will be used forDMA through virtio-fs. If these pages are backed by vmalloc(),{flush|invalidate}_kernel_vmap_range() are necessary to flush orinvalidate the cache before the DMA operation. So add two new fields infuse_args_pages to record the base address of vmalloc area and thecondition indicating whether invalidation is needed. Perform the flushin fuse_get_user_pages() for write operations and the invalidation infuse_release_user_pages() for read operations.It may seem necessary to introduce another fie---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bfa: Fix use-after-free in bfad_im_module_exit()BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303Call Trace: dump_stack_lvl+0x95/0xe0 print_report+0xcb/0x620 kasan_report+0xbd/0xf0 __lock_acquire+0x2aca/0x3a20 lock_acquire+0x19b/0x520 _raw_spin_lock+0x2b/0x40 attribute_container_unregister+0x30/0x160 fc_release_transport+0x19/0x90 [scsi_transport_fc] bfad_im_module_exit+0x23/0x60 [bfa] bfad_init+0xdb/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 fc_attach_transport+0x4f/0x4740 [scsi_transport_fc] bfad_im_module_init+0x17/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x38/0x50 kfree+0x212/0x480 bfad_im_module_init+0x7e/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fAbove issue happens as follows:bfad_init error = bfad_im_module_init() fc_release_transport(bfad_im_scsi_transport_template); if (error) goto ext;ext: bfad_im_module_exit(); fc_release_transport(bfad_im_scsi_transport_template); --> Trigger double releaseDon't call bfad_im_module_exit() if bfad_im_module_init() failed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: bsg: Set bsg_queue to NULL after removalCurrently, this does not cause any issues, but I believe it is necessary toset bsg_queue to NULL after removing it to prevent potential use-after-free(UAF) access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Play nice with protected guests in complete_hypercall_exit()Use is_64_bit_hypercall() instead of is_64_bit_mode() to detect a 64-bithypercall when completing said hypercall. For guests with protected state,e.g. SEV-ES and SEV-SNP, KVM must assume the hypercall was made in 64-bitmode as the vCPU state needed to detect 64-bit mode is unavailable.Hacking the sev_smoke_test selftest to generate a KVM_HC_MAP_GPA_RANGEhypercall via VMGEXIT trips the WARN: ------------[ cut here ]------------ WARNING: CPU: 273 PID: 326626 at arch/x86/kvm/x86.h:180 complete_hypercall_exit+0x44/0xe0 [kvm] Modules linked in: kvm_amd kvm ... [last unloaded: kvm] CPU: 273 UID: 0 PID: 326626 Comm: sev_smoke_test Not tainted 6.12.0-smp--392e932fa0f3-feat #470 Hardware name: Google Astoria/astoria, BIOS 0.20240617.0-0 06/17/2024 RIP: 0010:complete_hypercall_exit+0x44/0xe0 [kvm] Call Trace: kvm_arch_vcpu_ioctl_run+0x2400/0x2720 [kvm] kvm_vcpu_ioctl+0x54f/0x630 [kvm] __se_sys_ioctl+0x6b/0xc0 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/modes: Avoid divide by zero harder in drm_mode_vrefresh()drm_mode_vrefresh() is trying to avoid divide by zeroby checking whether htotal or vtotal are zero. But we maystill end up with a div-by-zero of vtotal*htotal*...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: zynqmp_kms: Unplug DRM device before removalPrevent userspace accesses to the DRM device from causinguse-after-frees by unplugging the device before we remove it. Thiscauses any further userspace accesses to result in an error withoutfurther calls into this driver's internals.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xferThe AD7923 was updated to support devices with 8 channels, but the sizeof tx_buf and ring_xfer was not increased accordingly, leading to apotential buffer overflow in ad7923_update_scan_mode().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ovl: Filter invalid inodes with missing lookup functionAdd a check to the ovl_dentry_weird() function to prevent theprocessing of directory inodes that lack the lookup function.This is important because such inodes can cause errors in overlayfswhen passed to the lowerstack.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Ensure power suppliers be suspended before detach themThe power suppliers are always requested to suspend asynchronously,dev_pm_domain_detach() requires the caller to ensure propersynchronization of this function with power management callbacks.otherwise the detach may led to kernel panic, like below:[ 1457.107934] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040[ 1457.116777] Mem abort info:[ 1457.119589] ESR = 0x0000000096000004[ 1457.123358] EC = 0x25: DABT (current EL), IL = 32 bits[ 1457.128692] SET = 0, FnV = 0[ 1457.131764] EA = 0, S1PTW = 0[ 1457.134920] FSC = 0x04: level 0 translation fault[ 1457.139812] Data abort info:[ 1457.142707] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 1457.148196] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 1457.153256] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 1457.158563] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001138b6000[ 1457.165000] [0000000000000040] pgd=0000000000000000, p4d=0000000000000000[ 1457.171792] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[ 1457.178045] Modules linked in: v4l2_jpeg wave6_vpu_ctrl(-) [last unloaded: mxc_jpeg_encdec][ 1457.186383] CPU: 0 PID: 51938 Comm: kworker/0:3 Not tainted 6.6.36-gd23d64eea511 #66[ 1457.194112] Hardware name: NXP i.MX95 19X19 board (DT)[ 1457.199236] Workqueue: pm pm_runtime_work[ 1457.203247] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 1457.210188] pc : genpd_runtime_suspend+0x20/0x290[ 1457.214886] lr : __rpm_callback+0x48/0x1d8[ 1457.218968] sp : ffff80008250bc50[ 1457.222270] x29: ffff80008250bc50 x28: 0000000000000000 x27: 0000000000000000[ 1457.229394] x26: 0000000000000000 x25: 0000000000000008 x24: 00000000000f4240[ 1457.236518] x23: 0000000000000000 x22: ffff00008590f0e4 x21: 0000000000000008[ 1457.243642] x20: ffff80008099c434 x19: ffff00008590f000 x18: ffffffffffffffff[ 1457.250766] x17: 5300326563697665 x16: 645f676e696c6f6f x15: 63343a6d726f6674[ 1457.257890] x14: 0000000000000004 x13: 00000000000003a4 x12: 0000000000000002[ 1457.265014] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff80008250bbb0[ 1457.272138] x8 : ffff000092937200 x7 : ffff0003fdf6af80 x6 : 0000000000000000[ 1457.279262] x5 : 00000000410fd050 x4 : 0000000000200000 x3 : 0000000000000000[ 1457.286386] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008590f000[ 1457.293510] Call trace:[ 1457.295946] genpd_runtime_suspend+0x20/0x290[ 1457.300296] __rpm_callback+0x48/0x1d8[ 1457.304038] rpm_callback+0x6c/0x78[ 1457.307515] rpm_suspend+0x10c/0x570[ 1457.311077] pm_runtime_work+0xc4/0xc8[ 1457.314813] process_one_work+0x138/0x248[ 1457.318816] worker_thread+0x320/0x438[ 1457.322552] kthread+0x110/0x114[ 1457.325767] ret_from_fork+0x10/0x20
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: tc358743: Fix crash in the probe error path when using pollingIf an error occurs in the probe() function, we should remove the pollingtimer that was alarmed earlier, otherwise the timer is called witharguments that are already freed, which results in a crash.------------[ cut here ]------------WARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268Modules linked in:CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226Hardware name: Diasom DS-RK3568-SOM-EVB (DT)pstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __run_timers+0x244/0x268lr : __run_timers+0x1d4/0x268sp : ffffff80eff2baf0x29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00x26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00x23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000x20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffffx17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003ex14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000x11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009x8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480x5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240x2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0Call trace: __run_timers+0x244/0x268 timer_expire_remote+0x50/0x68 tmigr_handle_remote+0x388/0x39c run_timer_softirq+0x38/0x44 handle_softirqs+0x138/0x298 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x24/0x4c do_softirq_own_stack+0x1c/0x2c irq_exit_rcu+0x9c/0xcc el1_interrupt+0x48/0xc0 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x7c/0x80 default_idle_call+0x34/0x68 do_idle+0x23c/0x294 cpu_startup_entry+0x38/0x3c secondary_start_kernel+0x128/0x160 __secondary_switched+0xb8/0xbc---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Set video drvdata before register video deviceThe video drvdata should be set before the video device is registered,otherwise video_drvdata() may return NULL in the open() file ops, and ledto oops.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: ref-verify: fix use-after-free after invalid ref actionAt btrfs_ref_tree_mod() after we successfully inserted the new ref entry(local variable 'ref') into the respective block entry's rbtree (localvariable 'be'), if we find an unexpected action of BTRFS_DROP_DELAYED_REF,we error out and free the ref entry without removing it from the blockentry's rbtree. Then in the error path of btrfs_ref_tree_mod() we callbtrfs_free_ref_cache(), which iterates over all block entries and thencalls free_block_entry() for each one, and there we will trigger ause-after-free when we are called against the block entry to which weadded the freed ref entry to its rbtree, since the rbtree still pointsto the block entry, as we didn't remove it from the rbtree before freeingit in the error path at btrfs_ref_tree_mod(). Fix this by removing thenew ref entry from the rbtree before freeing it.Syzbot report this with the following stack traces: BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_insert_empty_items+0x9c/0x1a0 fs/btrfs/ctree.c:4314 btrfs_insert_empty_item fs/btrfs/ctree.h:669 [inline] btrfs_insert_orphan_item+0x1f1/0x320 fs/btrfs/orphan.c:23 btrfs_orphan_add+0x6d/0x1a0 fs/btrfs/inode.c:3482 btrfs_unlink+0x267/0x350 fs/btrfs/inode.c:4293 vfs_unlink+0x365/0x650 fs/namei.c:4469 do_unlinkat+0x4ae/0x830 fs/namei.c:4533 __do_sys_unlinkat fs/namei.c:4576 [inline] __se_sys_unlinkat fs/namei.c:4569 [inline] __x64_sys_unlinkat+0xcc/0xf0 fs/namei.c:4569 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f BTRFS error (device loop0 state EA): Ref action 1, root 5, ref_root 5, parent 0, owner 260, offset 0, num_refs 1 __btrfs_mod_ref+0x76b/0xac0 fs/btrfs/extent-tree.c:2521 update_ref_for_cow+0x96a/0x11f0 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_i---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: Fix warning in migrate_enable for boosted tasksWhen running the following command:while true; do stress-ng --cyclic 30 --timeout 30s --minimize --quietdonea warning is eventually triggered:WARNING: CPU: 43 PID: 2848 at kernel/sched/deadline.c:794setup_new_dl_entity+0x13e/0x180...Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? enqueue_dl_entity+0x631/0x6e0 ? setup_new_dl_entity+0x13e/0x180 ? __warn+0x7e/0xd0 ? report_bug+0x11a/0x1a0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 enqueue_dl_entity+0x631/0x6e0 enqueue_task_dl+0x7d/0x120 __do_set_cpus_allowed+0xe3/0x280 __set_cpus_allowed_ptr_locked+0x140/0x1d0 __set_cpus_allowed_ptr+0x54/0xa0 migrate_enable+0x7e/0x150 rt_spin_unlock+0x1c/0x90 group_send_sig_info+0xf7/0x1a0 ? kill_pid_info+0x1f/0x1d0 kill_pid_info+0x78/0x1d0 kill_proc_info+0x5b/0x110 __x64_sys_kill+0x93/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f0dab31f92bThis warning occurs because set_cpus_allowed dequeues and enqueues taskswith the ENQUEUE_RESTORE flag set. If the task is boosted, the warningis triggered. A boosted task already had its parameters set byrt_mutex_setprio, and a new call to setup_new_dl_entity is unnecessary,hence the WARN_ON call.Check if we are requeueing a boosted task and avoid callingsetup_new_dl_entity if that's the case.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/tctx: work around xa_store() allocation error issuesyzbot triggered the following WARN_ON:WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51which is theWARN_ON_ONCE(!xa_empty(&tctx->xa));sanity check in __io_uring_free() when a io_uring_task is going throughits final put. The syzbot test case includes injecting memory allocationfailures, and it very much looks like xa_store() can fail one of itsmemory allocations and end up with ->head being non-NULL even though noentries exist in the xarray.Until this issue gets sorted out, work around it by attempting toiterate entries in our xarray, and WARN_ON_ONCE() if one is found.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Add cond_resched() for no forced preemption modelFor no forced preemption model kernel, in the scenario where theexpander is connected to 12 high performance SAS SSDs, the followingcall trace may occur:[ 214.409199][ C240] watchdog: BUG: soft lockup - CPU#240 stuck for 22s! [irq/149-hisi_sa:3211][ 214.568533][ C240] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)[ 214.575224][ C240] pc : fput_many+0x8c/0xdc[ 214.579480][ C240] lr : fput+0x1c/0xf0[ 214.583302][ C240] sp : ffff80002de2b900[ 214.587298][ C240] x29: ffff80002de2b900 x28: ffff1082aa412000[ 214.593291][ C240] x27: ffff3062a0348c08 x26: ffff80003a9f6000[ 214.599284][ C240] x25: ffff1062bbac5c40 x24: 0000000000001000[ 214.605277][ C240] x23: 000000000000000a x22: 0000000000000001[ 214.611270][ C240] x21: 0000000000001000 x20: 0000000000000000[ 214.617262][ C240] x19: ffff3062a41ae580 x18: 0000000000010000[ 214.623255][ C240] x17: 0000000000000001 x16: ffffdb3a6efe5fc0[ 214.629248][ C240] x15: ffffffffffffffff x14: 0000000003ffffff[ 214.635241][ C240] x13: 000000000000ffff x12: 000000000000029c[ 214.641234][ C240] x11: 0000000000000006 x10: ffff80003a9f7fd0[ 214.647226][ C240] x9 : ffffdb3a6f0482fc x8 : 0000000000000001[ 214.653219][ C240] x7 : 0000000000000002 x6 : 0000000000000080[ 214.659212][ C240] x5 : ffff55480ee9b000 x4 : fffffde7f94c6554[ 214.665205][ C240] x3 : 0000000000000002 x2 : 0000000000000020[ 214.671198][ C240] x1 : 0000000000000021 x0 : ffff3062a41ae5b8[ 214.677191][ C240] Call trace:[ 214.680320][ C240] fput_many+0x8c/0xdc[ 214.684230][ C240] fput+0x1c/0xf0[ 214.687707][ C240] aio_complete_rw+0xd8/0x1fc[ 214.692225][ C240] blkdev_bio_end_io+0x98/0x140[ 214.696917][ C240] bio_endio+0x160/0x1bc[ 214.701001][ C240] blk_update_request+0x1c8/0x3bc[ 214.705867][ C240] scsi_end_request+0x3c/0x1f0[ 214.710471][ C240] scsi_io_completion+0x7c/0x1a0[ 214.715249][ C240] scsi_finish_command+0x104/0x140[ 214.720200][ C240] scsi_softirq_done+0x90/0x180[ 214.724892][ C240] blk_mq_complete_request+0x5c/0x70[ 214.730016][ C240] scsi_mq_done+0x48/0xac[ 214.734194][ C240] sas_scsi_task_done+0xbc/0x16c [libsas][ 214.739758][ C240] slot_complete_v3_hw+0x260/0x760 [hisi_sas_v3_hw][ 214.746185][ C240] cq_thread_v3_hw+0xbc/0x190 [hisi_sas_v3_hw][ 214.752179][ C240] irq_thread_fn+0x34/0xa4[ 214.756435][ C240] irq_thread+0xc4/0x130[ 214.760520][ C240] kthread+0x108/0x13c[ 214.764430][ C240] ret_from_fork+0x10/0x18This is because in the hisi_sas driver, both the hardware interrupthandler and the interrupt thread are executed on the same CPU. In theperformance test scenario, function irq_wait_for_interrupt() will alwaysreturn 0 if lots of interrupts occurs and the CPU will be continuouslyconsumed. As a result, the CPU cannot run the watchdog thread. When thewatchdog time exceeds the specified time, call trace occurs.To fix it, add cond_resched() to execute the watchdog thread.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Call free_htab_elem() after htab_unlock_bucket()For htab of maps, when the map is removed from the htab, it may hold thelast reference of the map. bpf_map_fd_put_ptr() will invokebpf_map_free_id() to free the id of the removed map element. However,bpf_map_fd_put_ptr() is invoked while holding a bucket lock(raw_spin_lock_t), and bpf_map_free_id() attempts to acquire map_idr_lock(spinlock_t), triggering the following lockdep warning: ============================= [ BUG: Invalid wait context ] 6.11.0-rc4+ #49 Not tainted ----------------------------- test_maps/4881 is trying to lock: ffffffff84884578 (map_idr_lock){+...}-{3:3}, at: bpf_map_free_id.part.0+0x21/0x70 other info that might help us debug this: context-{5:5} 2 locks held by test_maps/4881: #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, at: bpf_fd_htab_map_update_elem+0xf9/0x270 #1: ffff888149ced148 (&htab->lockdep_key#2){....}-{2:2}, at: htab_map_update_elem+0x178/0xa80 stack backtrace: CPU: 0 UID: 0 PID: 4881 Comm: test_maps Not tainted 6.11.0-rc4+ #49 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ... Call Trace: dump_stack_lvl+0x6e/0xb0 dump_stack+0x10/0x20 __lock_acquire+0x73e/0x36c0 lock_acquire+0x182/0x450 _raw_spin_lock_irqsave+0x43/0x70 bpf_map_free_id.part.0+0x21/0x70 bpf_map_put+0xcf/0x110 bpf_map_fd_put_ptr+0x9a/0xb0 free_htab_elem+0x69/0xe0 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 bpf_map_update_value+0x266/0x380 __sys_bpf+0x21bb/0x36b0 __x64_sys_bpf+0x45/0x60 x64_sys_call+0x1b2a/0x20d0 do_syscall_64+0x5d/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7eOne way to fix the lockdep warning is using raw_spinlock_t formap_idr_lock as well. However, bpf_map_alloc_id() invokesidr_alloc_cyclic() after acquiring map_idr_lock, it will trigger asimilar lockdep warning because the slab's lock (s->cpu_slab->lock) isstill a spinlock.Instead of changing map_idr_lock's type, fix the issue by invokinghtab_put_fd_value() after htab_unlock_bucket(). However, only deferringthe invocation of htab_put_fd_value() is not enough, because the old mappointers in htab of maps can not be saved during batched deletion.Therefore, also defer the invocation of free_htab_elem(), so theseto-be-freed elements could be linked together similar to lru map.There are four callers for ->map_fd_put_ptr:(1) alloc_htab_elem() (through htab_put_fd_value())It invokes ->map_fd_put_ptr() under a raw_spinlock_t. The invocation ofhtab_put_fd_value() can not simply move after htab_unlock_bucket(),because the old element has already been stashed in htab->extra_elems.It may be reused immediately after htab_unlock_bucket() and theinvocation of htab_put_fd_value() after htab_unlock_bucket() may releasethe newly-added element incorrectly. Therefore, saving the map pointerof the old element for htab of maps before unlocking the bucket andreleasing the map_ptr after unlock. Beside the map pointer in the oldelement, should do the same thing for the special fields in the oldelement as well.(2) free_htab_elem() (through htab_put_fd_value())Its caller includes __htab_map_lookup_and_delete_elem(),htab_map_delete_elem() and __htab_map_lookup_and_delete_batch().For htab_map_delete_elem(), simply invoke free_htab_elem() afterhtab_unlock_bucket(). For __htab_map_lookup_and_delete_batch(), justlike lru map, linking the to-be-freed element into node_to_free listand invoking free_htab_elem() for these element after unlock. It is safeto reuse batch_flink as the link for node_to_free, because theseelements have been removed from the hash llist.Because htab of maps doesn't support lookup_and_delete operation,__htab_map_lookup_and_delete_elem() doesn't have the problem, so keptit as---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()This patch fixes a NULL pointer dereference bug in brcmfmac that occurswhen a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBsare sent from the pkt queue.The problem is the number of entries in the pre-allocated sgtable, it isnents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1.Given the default [rt]xglom_size=32 it's actually 35 which is too small.Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKBis added for each original SKB if tailroom isn't enough to hold tail_pad.At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop"in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next returnNULL and this causes the oops.The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handlethe worst-case.Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464additional bytes of memory.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: set the right AMDGPU sg segment limitationThe driver needs to set the correct max_segment_size;otherwise debug_dma_map_sg() will complain about theover-mapping of the AMDGPU sg length as following:WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370[ 364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd[ 364.049532] ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii[ 364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G OE 6.10.0-custom #492[ 364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021[ 364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370[ 364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff <0f> 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05[ 364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286[ 364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027[ 364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680[ 364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930[ 364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000[ 364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800[ 364.049599] FS: 00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000[ 364.049601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0[ 364.049605] Call Trace:[ 364.049607] [ 364.049609] ? show_regs+0x6d/0x80[ 364.049614] ? __warn+0x8c/0x140[ 364.049618] ? debug_dma_map_sg+0x2dc/0x370[ 364.049621] ? report_bug+0x193/0x1a0[ 364.049627] ? handle_bug+0x46/0x80[ 364.049631] ? exc_invalid_op+0x1d/0x80[ 364.049635] ? asm_exc_invalid_op+0x1f/0x30[ 364.049642] ? debug_dma_map_sg+0x2dc/0x370[ 364.049647] __dma_map_sg_attrs+0x90/0xe0[ 364.049651] dma_map_sgtable+0x25/0x40[ 364.049654] amdgpu_bo_move+0x59a/0x850 [amdgpu][ 364.049935] ? srso_return_thunk+0x5/0x5f[ 364.049939] ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu][ 364.050095] ttm_bo_handle_move_mem+0xc3/0x180 [ttm][ 364.050103] ttm_bo_validate+0xc1/0x160 [ttm][ 364.050108] ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu][ 364.050263] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu][ 364.050473] kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu][ 364.050680] kfd_ioctl+0x3c2/0x530 [amdgpu][ 364.050866] ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu][ 364.05105---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: add a check to prevent array-index-out-of-bounds in dbAdjTreeWhen the value of lp is 0 at the beginning of the for loop, it willbecome negative in the next assignment and we should bail out.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix array-index-out-of-bounds in jfs_readdirThe stbl might contain some invalid values. Added a check toreturn error code in that case.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: af_can: do not leave a dangling sk pointer in can_create()On error can_create() frees the allocated sk object, but sock_init_data()has already attached it to the provided sock object. This will leave adangling sk pointer in the sock object and may cause use-after-free later.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_packet: avoid erroring out after sock_init_data() in packet_create()After sock_init_data() the allocated sk object is attached to the providedsock object. On error, packet_create() frees the sk object leaving thedangling pointer in the sock object on return. Some other code may tryto use this pointer and cause use-after-free.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MMWe currently assume that there is at least one VMA in a MM, which isn'ttrue.So we might end up having find_vma() return NULL, to then de-referenceNULL. So properly handle find_vma() returning NULL.This fixes the report:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194Code: ...RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709 __do_sys_migrate_pages mm/mempolicy.c:1727 [inline] __se_sys_migrate_pages mm/mempolicy.c:1723 [inline] __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f[akpm@linux-foundation.org: add unlikely()]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xsk: fix OOB map writes when deleting elementsJordy says:"In the xsk_map_delete_elem function an unsigned integer(map->max_entries) is compared with a user-controlled signed integer(k). Due to implicit type conversion, a large unsigned value formap->max_entries can bypass the intended bounds check: if (k >= map->max_entries) return -EINVAL;This allows k to hold a negative value (between -2147483648 and -2),which is then used as an array index in m->xsk_map[k], which resultsin an out-of-bounds access. spin_lock_bh(&m->lock); map_entry = &m->xsk_map[k]; // Out-of-bounds map_entry old_xs = unrcu_pointer(xchg(map_entry, NULL)); // Oob write if (old_xs) xsk_map_sock_delete(old_xs, map_entry); spin_unlock_bh(&m->lock);The xchg operation can then be used to cause an out-of-bounds write.Moreover, the invalid map_entry passed to xsk_map_sock_delete can leadto further memory corruption."It indeed results in following splat:[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108[76612.904330] #PF: supervisor write access in kernel mode[76612.909639] #PF: error_code(0x0002) - not-present page[76612.914855] PGD 0 P4D 0[76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP[76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470[76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60[76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff <48> 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31[76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246[76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000[76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000[76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007[76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8[76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0[76613.005303] FS: 00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000[76613.013517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0[76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[76613.041086] PKRU: 55555554[76613.043842] Call Trace:[76613.046331] [76613.048468] ? __die+0x20/0x60[76613.051581] ? page_fault_oops+0x15a/0x450[76613.055747] ? search_extable+0x22/0x30[76613.059649] ? search_bpf_extables+0x5f/0x80[76613.063988] ? exc_page_fault+0xa9/0x140[76613.067975] ? asm_exc_page_fault+0x22/0x30[76613.072229] ? xsk_map_delete_elem+0x2d/0x60[76613.076573] ? xsk_map_delete_elem+0x23/0x60[76613.080914] __sys_bpf+0x19b7/0x23c0[76613.084555] __x64_sys_bpf+0x1a/0x20[76613.088194] do_syscall_64+0x37/0xb0[76613.091832] entry_SYSCALL_64_after_hwframe+0x4b/0x53[76613.096962] RIP: 0033:0x7f80b6d1e88d[76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48[76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141[76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d[76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003[76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000[76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8[76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix OOB devmap writes when deleting elementsJordy reported issue against XSKMAP which also applies to DEVMAP - theindex used for accessing map entry, due to being a signed integer,causes the OOB writes. Fix is simple as changing the type from int tou32, however, when compared to XSKMAP case, one more thing needs to beaddressed.When map is released from system via dev_map_free(), we iterate throughall of the entries and an iterator variable is also an int, whichimplies OOB accesses. Again, change it to be u32.Example splat below:[ 160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000[ 160.731662] #PF: supervisor read access in kernel mode[ 160.736876] #PF: error_code(0x0000) - not-present page[ 160.742095] PGD 0 P4D 0[ 160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP[ 160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487[ 160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[ 160.767642] Workqueue: events_unbound bpf_map_free_deferred[ 160.773308] RIP: 0010:dev_map_free+0x77/0x170[ 160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 <48> 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff[ 160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202[ 160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024[ 160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000[ 160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001[ 160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122[ 160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000[ 160.838310] FS: 0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000[ 160.846528] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0[ 160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 160.874092] PKRU: 55555554[ 160.876847] Call Trace:[ 160.879338] [ 160.881477] ? __die+0x20/0x60[ 160.884586] ? page_fault_oops+0x15a/0x450[ 160.888746] ? search_extable+0x22/0x30[ 160.892647] ? search_bpf_extables+0x5f/0x80[ 160.896988] ? exc_page_fault+0xa9/0x140[ 160.900973] ? asm_exc_page_fault+0x22/0x30[ 160.905232] ? dev_map_free+0x77/0x170[ 160.909043] ? dev_map_free+0x58/0x170[ 160.912857] bpf_map_free_deferred+0x51/0x90[ 160.917196] process_one_work+0x142/0x370[ 160.921272] worker_thread+0x29e/0x3b0[ 160.925082] ? rescuer_thread+0x4b0/0x4b0[ 160.929157] kthread+0xd4/0x110[ 160.932355] ? kthread_park+0x80/0x80[ 160.936079] ret_from_fork+0x2d/0x50[ 160.943396] ? kthread_park+0x80/0x80[ 160.950803] ret_from_fork_asm+0x11/0x20[ 160.958482]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/dp_mst: Fix MST sideband message body length checkFix the MST sideband message body length check, which must be at least 1byte accounting for the message body CRC (aka message data CRC) at theend of the message.This fixes a case where an MST branch device returns a header with acorrect header CRC (indicating a correctly received body length), withthe body length being incorrectly set to 0. This will later lead to amemory corruption in drm_dp_sideband_append_payload() and the followingerrors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type 'u8 [48]' Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field "&msg->msg[msg->curlen]" at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: sysfs: Prevent div by zeroPrevent a division by 0 when monitoring is not enabled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: wacom: fix when get product name maybe null pointerDue to incorrect dev->product reporting by certain devices, nullpointer dereferences occur when dev->product is empty, leading topotential system crashes.This issue was found on EXCELSIOR DL37-D05 device withLoongson-LS3A6000-7A2000-DL37 motherboard.Kernel logs:[ 56.470885] usb 4-3: new full-speed USB device number 4 using ohci-pci[ 56.671638] usb 4-3: string descriptor 0 read error: -22[ 56.671644] usb 4-3: New USB device found, idVendor=056a, idProduct=0374, bcdDevice= 1.07[ 56.671647] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3[ 56.678839] hid-generic 0003:056A:0374.0004: hiddev0,hidraw3: USB HID v1.10 Device [HID 056a:0374] on usb-0000:00:05.0-3/input0[ 56.697719] CPU 2 Unable to handle kernel paging request at virtual address 0000000000000000, era == 90000000066e35c8, ra == ffff800004f98a80[ 56.697732] Oops[#1]:[ 56.697734] CPU: 2 PID: 2742 Comm: (udev-worker) Tainted: G OE 6.6.0-loong64-desktop #25.00.2000.015[ 56.697737] Hardware name: Inspur CE520L2/C09901N000000000, BIOS 2.09.00 10/11/2024[ 56.697739] pc 90000000066e35c8 ra ffff800004f98a80 tp 9000000125478000 sp 900000012547b8a0[ 56.697741] a0 0000000000000000 a1 ffff800004818b28 a2 0000000000000000 a3 0000000000000000[ 56.697743] a4 900000012547b8f0 a5 0000000000000000 a6 0000000000000000 a7 0000000000000000[ 56.697745] t0 ffff800004818b2d t1 0000000000000000 t2 0000000000000003 t3 0000000000000005[ 56.697747] t4 0000000000000000 t5 0000000000000000 t6 0000000000000000 t7 0000000000000000[ 56.697748] t8 0000000000000000 u0 0000000000000000 s9 0000000000000000 s0 900000011aa48028[ 56.697750] s1 0000000000000000 s2 0000000000000000 s3 ffff800004818e80 s4 ffff800004810000[ 56.697751] s5 90000001000b98d0 s6 ffff800004811f88 s7 ffff800005470440 s8 0000000000000000[ 56.697753] ra: ffff800004f98a80 wacom_update_name+0xe0/0x300 [wacom][ 56.697802] ERA: 90000000066e35c8 strstr+0x28/0x120[ 56.697806] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)[ 56.697816] PRMD: 0000000c (PPLV0 +PIE +PWE)[ 56.697821] EUEN: 00000000 (-FPE -SXE -ASXE -BTE)[ 56.697827] ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)[ 56.697831] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)[ 56.697835] BADV: 0000000000000000[ 56.697836] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000)[ 56.697838] Modules linked in: wacom(+) bnep bluetooth rfkill qrtr nls_iso8859_1 nls_cp437 snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore input_leds mousedev led_class joydev deepin_netmonitor(OE) fuse nfnetlink dmi_sysfs ip_tables x_tables overlay amdgpu amdxcp drm_exec gpu_sched drm_buddy radeon drm_suballoc_helper i2c_algo_bit drm_ttm_helper r8169 ttm drm_display_helper spi_loongson_pci xhci_pci cec xhci_pci_renesas spi_loongson_core hid_generic realtek gpio_loongson_64bit[ 56.697887] Process (udev-worker) (pid: 2742, threadinfo=00000000aee0d8b4, task=00000000a9eff1f3)[ 56.697890] Stack : 0000000000000000 ffff800004817e00 0000000000000000 0000251c00000000[ 56.697896] 0000000000000000 00000011fffffffd 0000000000000000 0000000000000000[ 56.697901] 0000000000000000 1b67a968695184b9 0000000000000000 90000001000b98d0[ 56.697906] 90000001000bb8d0 900000011aa48028 0000000000000000 ffff800004f9d74c[ 56.697911] 90000001000ba000 ffff800004f9ce58 0000000000000000 ffff800005470440[ 56.697916] ffff800004811f88 90000001000b98d0 9000000100da2aa8 90000001000bb8d0[ 56.697921] 0000000000000000 90000001000ba000 900000011aa48028 ffff800004f9d74c[ 56.697926] ffff8000054704e8 90000001000bb8b8 90000001000ba000 0000000000000000[ 56.697931] 90000001000bb8d0 ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: free inode when ocfs2_get_init_inode() failssyzbot is reporting busy inodes after unmount, for commit 9c89fe0af826("ocfs2: Handle error from dquot_initialize()") forgot to call iput() whennew_inode() succeeded and dquot_initialize() failed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsgThe current sk memory accounting logic in __SK_REDIRECT is pre-unchargingtosend bytes, which is either msg->sg.size or a smaller value apply_bytes.Potential problems with this strategy are as follows:- If the actual sent bytes are smaller than tosend, we need to charge some bytes back, as in line 487, which is okay but seems not clean.- When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may miss uncharging (msg->sg.size - apply_bytes) bytes.[...]415 tosend = msg->sg.size;416 if (psock->apply_bytes && psock->apply_bytes < tosend)417 tosend = psock->apply_bytes;[...]443 sk_msg_return(sk, msg, tosend);444 release_sock(sk);446 origsize = msg->sg.size;447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress,448 msg, tosend, flags);449 sent = origsize - msg->sg.size;[...]454 lock_sock(sk);455 if (unlikely(ret < 0)) {456 int free = sk_msg_free_nocharge(sk, msg);458 if (!cork)459 *copied -= free;460 }[...]487 if (eval == __SK_REDIRECT)488 sk_mem_charge(sk, tosend - sent);[...]When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply,the following warning will be reported:------------[ cut here ]------------WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0Modules linked in:CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014Workqueue: events sk_psock_destroyRIP: 0010:inet_sock_destruct+0x190/0x1a0RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100FS: 0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace:? __warn+0x89/0x130? inet_sock_destruct+0x190/0x1a0? report_bug+0xfc/0x1e0? handle_bug+0x5c/0xa0? exc_invalid_op+0x17/0x70? asm_exc_invalid_op+0x1a/0x20? inet_sock_destruct+0x190/0x1a0__sk_destruct+0x25/0x220sk_psock_destroy+0x2b2/0x310process_scheduled_works+0xa3/0x3e0worker_thread+0x117/0x240? __pfx_worker_thread+0x10/0x10kthread+0xcf/0x100? __pfx_kthread+0x10/0x10ret_from_fork+0x31/0x40? __pfx_kthread+0x10/0x10ret_from_fork_asm+0x1a/0x30---[ end trace 0000000000000000 ]---In __SK_REDIRECT, a more concise way is delaying the uncharging after sentbytes are finalized, and uncharge this value. When (ret < 0), we shallinvoke sk_msg_free.Same thing happens in case __SK_DROP, when tosend is set to apply_bytes,we may miss uncharging (msg->sg.size - apply_bytes) bytes. The samewarning will be reported in selftest.[...]468 case __SK_DROP:469 default:470 sk_msg_free_partial(sk, msg, tosend);471 sk_msg_apply_bytes(psock, tosend);472 *copied -= (tosend + delta);473 return -EACCES;[...]So instead of sk_msg_free_partial we can do sk_msg_free here.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: grgpio: Add NULL check in grgpio_probedevm_kasprintf() can return a NULL pointer on failure,but thisreturned value in grgpio_probe is not checked.Add NULL check in grgpio_probe, to handle kernel NULLpointer dereference error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix LGR and link use-after-free issueWe encountered a LGR/link use-after-free issue, which manifested asthe LGR/link refcnt reaching 0 early and entering the clear process,making resource access unsafe. refcount_t: addition on 0; use-after-free. WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140 Workqueue: events smc_lgr_terminate_work [smc] Call trace: refcount_warn_saturate+0x9c/0x140 __smc_lgr_terminate.part.45+0x2a8/0x370 [smc] smc_lgr_terminate_work+0x28/0x30 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118or refcount_t: underflow; use-after-free. WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140 Workqueue: smc_hs_wq smc_listen_work [smc] Call trace: refcount_warn_saturate+0xf0/0x140 smcr_link_put+0x1cc/0x1d8 [smc] smc_conn_free+0x110/0x1b0 [smc] smc_conn_abort+0x50/0x60 [smc] smc_listen_find_device+0x75c/0x790 [smc] smc_listen_work+0x368/0x8a0 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118It is caused by repeated release of LGR/link refcnt. One suspect is thatsmc_conn_free() is called repeatedly because some smc_conn_free() fromserver listening path are not protected by sock lock.e.g.Calls under socklock | smc_listen_work-------------------------------------------------------lock_sock(sk) | smc_conn_abortsmc_conn_free | \- smc_conn_free\- smcr_link_put | \- smcr_link_put (duplicated)release_sock(sk)So here add sock lock protection in smc_listen_work() path, making itexclusive with other connection operations.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: initialize close_work early to avoid warningWe encountered a warning that close_work was canceled beforeinitialization. WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0 Workqueue: events smc_lgr_terminate_work [smc] RIP: 0010:__flush_work+0x19e/0x1b0 Call Trace: ? __wake_up_common+0x7a/0x190 ? work_busy+0x80/0x80 __cancel_work_timer+0xe3/0x160 smc_close_cancel_work+0x1a/0x70 [smc] smc_close_active_abort+0x207/0x360 [smc] __smc_lgr_terminate.part.38+0xc8/0x180 [smc] process_one_work+0x19e/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x117/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x22/0x30This is because when smc_close_cancel_work is triggered, e.g. the RDMAdriver is rmmod and the LGR is terminated, the conn->close_work isflushed before initialization, resulting in WARN_ON(!work->func).__smc_lgr_terminate | smc_connect_{rdma|ism}------------------------------------------------------------- | smc_conn_create | \- smc_lgr_register_connfor conn in lgr->conns_all |\- smc_conn_kill | \- smc_close_active_abort | \- smc_close_cancel_work | \- cancel_work_sync | \- __flush_work | (close_work) | | smc_close_init | \- INIT_WORK(&close_work)So fix this by initializing close_work before establishing theconnection.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix icmp host relookup triggering ip_rt_bugarp link failure may trigger ip_rt_bug while xfrm enabled, call trace is:WARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 ip_rt_bug+0x14/0x20Modules linked in:CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:ip_rt_bug+0x14/0x20Call Trace: ip_send_skb+0x14/0x40 __icmp_send+0x42d/0x6a0 ipv4_link_failure+0xe2/0x1d0 arp_error_report+0x3c/0x50 neigh_invalidate+0x8d/0x100 neigh_timer_handler+0x2e1/0x330 call_timer_fn+0x21/0x120 __run_timer_base.part.0+0x1c9/0x270 run_timer_softirq+0x4c/0x80 handle_softirqs+0xac/0x280 irq_exit_rcu+0x62/0x80 sysvec_apic_timer_interrupt+0x77/0x90The script below reproduces this scenario:ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \ dir out priority 0 ptype main flag localok icmpip l a veth1 type vethip a a 192.168.141.111/24 dev veth0ip l s veth0 upping 192.168.141.155 -c 1icmp_route_lookup() create input routes for locally generated packetswhile xfrm relookup ICMP traffic.Then it will set input route(dst->out = ip_rt_bug) to skb for DESTUNREACH.For ICMP err triggered by locally generated packets, dst->dev of outputroute is loopback. Generally, xfrm relookup verification is not requiredon loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1).Skip icmp relookup for locally generated packets to fix it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: control: Avoid WARN() for symlink errorsUsing WARN() for showing the error of symlink creations don't givemore information than telling that something goes wrong, since theusual code path is a lregister callback from each control elementcreation. More badly, the use of WARN() rather confuses fuzzer as ifit were serious issues.This patch downgrades the warning messages to use the normal dev_err()instead of WARN(). For making it clearer, add the function name tothe prefix, too.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: lapb: increase LAPB_HEADER_LENIt is unclear if net/lapb code is supposed to be ready for 8021q.We can at least avoid crashes like the following :skbuff: skb_under_panic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 !Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 1 UID: 0 PID: 5508 Comm: dhcpcd Not tainted 6.12.0-rc7-syzkaller-00144-g66418447d27b #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216Code: 0d 8d 48 c7 c6 2e 9e 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 1a 6f 37 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3RSP: 0018:ffffc90002ddf638 EFLAGS: 00010282RAX: 0000000000000086 RBX: dffffc0000000000 RCX: 7a24750e538ff600RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000RBP: ffff888034a86650 R08: ffffffff8174b13c R09: 1ffff920005bbe60R10: dffffc0000000000 R11: fffff520005bbe61 R12: 0000000000000140R13: ffff88802824a400 R14: ffff88802824a3fe R15: 0000000000000016FS: 00007f2a5990d740(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000110c2631fd CR3: 0000000029504000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 nr_header+0x36/0x320 net/netrom/nr_dev.c:69 dev_hard_header include/linux/netdevice.h:3148 [inline] vlan_dev_hard_header+0x359/0x480 net/8021q/vlan_dev.c:83 dev_hard_header include/linux/netdevice.h:3148 [inline] lapbeth_data_transmit+0x1f6/0x2a0 drivers/net/wan/lapbether.c:257 lapb_data_transmit+0x91/0xb0 net/lapb/lapb_iface.c:447 lapb_transmit_buffer+0x168/0x1f0 net/lapb/lapb_out.c:149 lapb_establish_data_link+0x84/0xd0 lapb_device_event+0x4e0/0x670 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:8922 devinet_ioctl+0xa4e/0x1aa0 net/ipv4/devinet.c:1188 inet_ioctl+0x3d7/0x4f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x158/0x460 net/socket.c:1227 sock_ioctl+0x626/0x8e0 net/socket.c:1346 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: DR, prevent potential error pointer dereferenceThe dr_domain_add_vport_cap() function generally returns NULL on errorbut sometimes we want it to return ERR_PTR(-EBUSY) so the caller canretry. The problem here is that "ret" can be either -EBUSY or -ENOMEMand if it's and -ENOMEM then the error pointer is propogated back andeventually dereferenced in dr_ste_v0_build_src_gvmi_qpn_tag().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf,perf: Fix invalid prog_array access in perf_event_detach_bpf_progSyzbot reported [1] crash that happens for following tracing scenario: - create tracepoint perf event with attr.inherit=1, attach it to the process and set bpf program to it - attached process forks -> chid creates inherited event the new child event shares the parent's bpf program and tp_event (hence prog_array) which is global for tracepoint - exit both process and its child -> release both events - first perf_event_detach_bpf_prog call will release tp_event->prog_array and second perf_event_detach_bpf_prog will crash, because tp_event->prog_array is NULLThe fix makes sure the perf_event_detach_bpf_prog checks prog_arrayis valid before it tries to remove the bpf program from it.[1] https://lore.kernel.org/bpf/Z1MR6dCIKajNS6nU@krava/T/#m91dbf0688221ec7a7fc95e896a7ef9ff93b0b8ad
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.cAdd error pointer check after calling otx2_mbox_get_rsp().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vc4: hdmi: Avoid hang with debug registers when suspendedTrying to read /sys/kernel/debug/dri/1/hdmi1_regswhen the hdmi is disconnected results in a fatal system hang.This is due to the pm suspend code disabling the dvp clock.That is just a gate of the 108MHz clock in DVP_HT_RPI_MISC_CONFIG,which results in accesses hanging AXI bus.Protect against this.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transportSince transport->sock has been set to NULL during reset transport,XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, thexs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()to dereference the transport->sock that has been set to NULL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C deviceWhile design wise the idea of converting the driver to usethe hierarchy of the IRQ chips is correct, the implementationhas (inherited) flaws. This was unveiled when platform_get_irq()had started WARN() on IRQ 0 that is supposed to be a LinuxIRQ number (also known as vIRQ).Rework the driver to respect IRQ domain when creating each MFDdevice separately, as the domain is not the same for all of them.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix recursive lock when verdict program return SK_PASSWhen the stream_verdict program returns SK_PASS, it places the received skbinto its own receive queue, but a recursive lock eventually occurs, leadingto an operating system deadlock. This issue has been present since v6.9.'''sk_psock_strp_data_ready write_lock_bh(&sk->sk_callback_lock) strp_data_ready strp_read_sock read_sock -> tcp_read_sock strp_recv cb.rcv_msg -> sk_psock_strp_read # now stream_verdict return SK_PASS without peer sock assign __SK_PASS = sk_psock_map_verd(SK_PASS, NULL) sk_psock_verdict_apply sk_psock_skb_ingress_self sk_psock_skb_ingress_enqueue sk_psock_data_ready read_lock_bh(&sk->sk_callback_lock) <= dead lock'''This topic has been discussed before, but it has not been fixed.Previous discussion:https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:9p/xen: fix release of IRQKernel logs indicate an IRQ was double-freed.Pass correct device ID during IRQ release.[Dominique: remove confusing variable reset to 0]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.cAdd error pointer checks after calling otx2_mbox_get_rsp().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: check if iowq is killed before queuingtask work can be executed after the task has gone through io_uringtermination, whether it's the final task_work run or the fallback path.In this case, task work will find ->io_wq being already killed andnull'ed, which is a problem if it then tries to forward the request toio_queue_iowq(). Make io_queue_iowq() fail requests in this case.Note that it also checks PF_KTHREAD, because the user can first closea DEFER_TASKRUN ring and shortly after kill the task, in which case->iowq check would race.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ionic: Fix netdev notifier unregister on failureIf register_netdev() fails, then the driver leaks the netdev notifier.Fix this by calling ionic_lif_unregister() on register_netdev()failure. This will also call ionic_lif_unregister_phc() if it hasalready been registered.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: prevent bad user input in nsim_dev_health_break_write()If either a zero count or a large one is provided, kernel can crash.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: fix TSO DMA API usage causing oopsCommit 66600fac7a98 ("net: stmmac: TSO: Fix unbalanced DMA map/unmapfor non-paged SKB data") moved the assignment of tx_skbuff_dma[]'smembers to be later in stmmac_tso_xmit().The buf (dma cookie) and len stored in this structure are passed todma_unmap_single() by stmmac_tx_clean(). The DMA API requires thatthe dma cookie passed to dma_unmap_single() is the same as the valuereturned from dma_map_single(). However, by moving the assignmentlater, this is not the case when priv->dma_cap.addr64 > 32 as "des"is offset by proto_hdr_len.This causes problems such as: dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failedand with DMA_API_DEBUG enabled: DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes]Fix this by maintaining "des" as the original DMA cookie, and usetso_des to pass the offset DMA cookie to stmmac_tso_allocator().Full details of the crashes can be found at:https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Several fixes to bpf_msg_pop_dataSeveral fixes to bpf_msg_pop_data,1. In sk_msg_shift_left, we should put_page2. if (len == 0), return early is better3. pop the entire sk_msg (last == msg->sg.size) should be supported4. Fix for the value of variable "a"5. In sk_msg_shift_left, after shifting, i has already pointed to the nextelement. Addtional sk_msg_iter_var_next may result in BUG.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix cpu stuck caused by printings during resetDuring reset, cmd to destroy resources such as qp, cq, and mr may fail,and error logs will be printed. When a large number of resources aredestroyed, there will be lots of printings, and it may lead to a cpustuck.Delete some unnecessary printings and replace other printing functionsin these paths with the ratelimited version.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devicesWhile design wise the idea of converting the driver to usethe hierarchy of the IRQ chips is correct, the implementationhas (inherited) flaws. This was unveiled when platform_get_irq()had started WARN() on IRQ 0 that is supposed to be a LinuxIRQ number (also known as vIRQ).Rework the driver to respect IRQ domain when creating each MFDdevice separately, as the domain is not the same for all of them.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU deviceWhile design wise the idea of converting the driver to usethe hierarchy of the IRQ chips is correct, the implementationhas (inherited) flaws. This was unveiled when platform_get_irq()had started WARN() on IRQ 0 that is supposed to be a LinuxIRQ number (also known as vIRQ).Rework the driver to respect IRQ domain when creating each MFDdevice separately, as the domain is not the same for all of them.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.cAdd error pointer check after calling otx2_mbox_get_rsp().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.cAdding error pointer check after calling otx2_mbox_get_rsp().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.cAdd error pointer check after calling otx2_mbox_get_rsp().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages()Fix an unwind issue in mlx5vf_add_migration_pages().If a set of pages is allocated but fails to be added to the SG table,they need to be freed to prevent a memory leak.Any pages successfully added to the SG table will be freed as part ofmlx5vf_free_data_buffer().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()Hook "qed_ops->common->sb_init = qed_sb_init" does not release the DMAmemory sb_virt when it fails. Add dma_free_coherent() to free it. Thisis the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Prevent bad count for tracing_cpumask_writeIf a large count is provided, it will trigger a warning in bitmap_parse_user.Also check zero for it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: add a sanity check for btrfs root in btrfs_search_slot()Syzbot reports a null-ptr-deref in btrfs_search_slot().The reproducer is using rescue=ibadroots, and the extent tree root iscorrupted thus the extent tree is NULL.When scrub tries to search the extent tree to gather the needed extentinfo, btrfs_search_slot() doesn't check if the target root is NULL ornot, resulting the null-ptr-deref.Add sanity check for btrfs root before using it in btrfs_search_slot().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occurThe action force umount(umount -f) will attempt to kill all rpc_task evenumount operation may ultimately fail if some files remain open.Consequently, if an action attempts to open a file, it can potentiallysend two rpc_task to nfs server. NFS CLIENTthread1 thread2open("file")...nfs4_do_open _nfs4_do_open _nfs4_open_and_get_state _nfs4_proc_open nfs4_run_open_task /* rpc_task1 */ rpc_run_task rpc_wait_for_completion_task umount -f nfs_umount_begin rpc_killall_tasks rpc_signal_task rpc_task1 been wakeup and return -512 _nfs4_do_open // while loop ... nfs4_run_open_task /* rpc_task2 */ rpc_run_task rpc_wait_for_completion_taskWhile processing an open request, nfsd will first attempt to find orallocate an nfs4_openowner. If it finds an nfs4_openowner that is notmarked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Sincetwo rpc_task can attempt to open the same file simultaneously from theclient to server, and because two instances of nfsd can runconcurrently, this situation can lead to lots of memory leak.Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will betriggered. NFS SERVERnfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threadsnfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // alloc oo1, stateid1 nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // find oo1, without NFS4_OO_CONFIRMED release_openowner unhash_openowner_locked list_del_init(&oo->oo_perclient) // cannot find this oo // from client, LEAK!!! alloc_stateowner // alloc oo2 nfsd4_process_open2 init_open_stateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4_get_vfs_file // alloc nfsd_file1 and nfsd_file_mark1 // all LEAK!!! nfsd4_process_open2 ... write_threads ... nfsd_destroy_serv nfsd_shutdown_net nfs4_state_shutdown_net nfs4_state_destroy_net destroy_client __destroy_client // won't find oo1!!! nfsd_shutdown_generic nfsd_file_cache_shutdown kmem_cache_destroy for nfsd_file_slab and nfsd_file_mark_slab // bark since nfsd_file1 // and nfsd_file_mark1 // still alive=======================================================================BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on__kmem_cache_shutdown()-----------------------------------------------------------------------Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014Call Trace: dum---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: imx8m: Probe the SoC driver as platform driverWith driver_async_probe=* on kernel command line, the following trace isproduced because on i.MX8M Plus hardware because the soc-imx8m.c drivercalls of_clk_get_by_name() which returns -EPROBE_DEFER because the clockdriver is not yet probed. This was not detected during regular testingwithout driver_async_probe.Convert the SoC code to platform driver and instantiate a platform devicein its current device_initcall() to probe the platform driver. Rework.soc_revision callback to always return valid error code and return SoCrevision via parameter. This way, if anything in the .soc_revision callbackreturn -EPROBE_DEFER, it gets propagated to .probe and the .probe will getretried later."------------[ cut here ]------------WARNING: CPU: 1 PID: 1 at drivers/soc/imx/soc-imx8m.c:115 imx8mm_soc_revision+0xdc/0x180CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-next-20240924-00002-g2062bb554dea #603Hardware name: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3) (DT)pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : imx8mm_soc_revision+0xdc/0x180lr : imx8mm_soc_revision+0xd0/0x180sp : ffff8000821fbcc0x29: ffff8000821fbce0 x28: 0000000000000000 x27: ffff800081810120x26: ffff8000818a9970 x25: 0000000000000006 x24: 0000000000824311x23: ffff8000817f42c8 x22: ffff0000df8be210 x21: fffffffffffffdfbx20: ffff800082780000 x19: 0000000000000001 x18: ffffffffffffffffx17: ffff800081fff418 x16: ffff8000823e1000 x15: ffff0000c03b65e8x14: ffff0000c00051b0 x13: ffff800082790000 x12: 0000000000000801x11: ffff80008278ffff x10: ffff80008209d3a6 x9 : ffff80008062e95cx8 : ffff8000821fb9a0 x7 : 0000000000000000 x6 : 00000000000080e3x5 : ffff0000df8c03d8 x4 : 0000000000000000 x3 : 0000000000000000x2 : 0000000000000000 x1 : fffffffffffffdfb x0 : fffffffffffffdfbCall trace: imx8mm_soc_revision+0xdc/0x180 imx8_soc_init+0xb0/0x1e0 do_one_initcall+0x94/0x1a8 kernel_init_freeable+0x240/0x2a8 kernel_init+0x28/0x140 ret_from_fork+0x10/0x20---[ end trace 0000000000000000 ]---SoC: i.MX8MP revision 1.1"
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: megaraid_sas: Fix for a potential deadlockThis fixes a 'possible circular locking dependency detected' warning CPU0 CPU1 ---- ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex); lock(&shost->scan_mutex);Fix this by temporarily releasing the reset_mutex.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: imx6: Fix suspend/resume support on i.MX6QDLThe suspend/resume functionality is currently broken on the i.MX6QDLplatform, as documented in the NXP errata (ERR005723): https://www.nxp.com/docs/en/errata/IMX6DQCE.pdfThis patch addresses the issue by sharing most of the suspend/resumesequences used by other i.MX devices, while avoiding modifications tocritical registers that disrupt the PCIe functionality. It targets thesame problem as the following downstream commit: https://github.com/nxp-imx/linux-imx/commit/4e92355e1f79d225ea842511fcfd42b343b32995Unlike the downstream commit, this patch also resets the connected PCIedevice if possible. Without this reset, certain drivers, such as ath10kor iwlwifi, will crash on resume. The device reset is also done by thedriver on other i.MX platforms, making this patch consistent withexisting practices.Upon resuming, the kernel will hang and display an error. Here's anexample of the error encountered with the ath10k driver: ath10k_pci 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible Unhandled fault: imprecise external abort (0x1406) at 0x0106f944Without this patch, suspend/resume will fail on i.MX6QDL devices if aPCIe device is connected.[kwilczynski: commit log, added tag for stable releases]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_threadsyzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1]If dvb->mux is not initialized successfully by vidtv_mux_init() in thevidtv_start_streaming(), it will trigger null pointer dereference about muxin vidtv_mux_stop_thread().Adjust the timing of streaming initialization and check it beforestopping it.[1]KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f]CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline] vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3f8/0xb60 fs/file_table.c:450 task_work_run+0x14e/0x250 kernel/task_work.c:239 get_signal+0x1d3/0x2610 kernel/signal.c:2790 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim()The task sometimes continues looping in throttle_direct_reclaim() becauseallow_direct_reclaim(pgdat) keeps returning false. #0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c #2 [ffff80002cb6f990] schedule at ffff800008abc50c #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550 #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68 #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660 #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98 #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8 #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974 #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4At this point, the pgdat contains the following two zones: NODE: 4 ZONE: 0 ADDR: ffff00817fffe540 NAME: "DMA32" SIZE: 20480 MIN/LOW/HIGH: 11/28/45 VM_STAT: NR_FREE_PAGES: 359 NR_ZONE_INACTIVE_ANON: 18813 NR_ZONE_ACTIVE_ANON: 0 NR_ZONE_INACTIVE_FILE: 50 NR_ZONE_ACTIVE_FILE: 0 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0 NODE: 4 ZONE: 1 ADDR: ffff00817fffec00 NAME: "Normal" SIZE: 8454144 PRESENT: 98304 MIN/LOW/HIGH: 68/166/264 VM_STAT: NR_FREE_PAGES: 146 NR_ZONE_INACTIVE_ANON: 94668 NR_ZONE_ACTIVE_ANON: 3 NR_ZONE_INACTIVE_FILE: 735 NR_ZONE_ACTIVE_FILE: 78 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0In allow_direct_reclaim(), while processing ZONE_DMA32, the sum ofinactive/active file-backed pages calculated in zone_reclaimable_pages()based on the result of zone_page_state_snapshot() is zero. Additionally, since this system lacks swap, the calculation of inactive/active anonymous pages is skipped. crash> p nr_swap_pages nr_swap_pages = $1937 = { counter = 0 }As a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on tothe processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 havingfree pages significantly exceeding the high watermark.The problem is that the pgdat->kswapd_failures hasn't been incremented. crash> px ((struct pglist_data *) 0xffff00817fffe540)->kswapd_failures $1935 = 0x0This is because the node deemed balanced. The node balancing logic inbalance_pgdat() evaluates all zones collectively. If one or more zones(e.g., ZONE_DMA32) have enough free pages to meet their watermarks, theentire node is deemed balanced. This causes balance_pgdat() to exit earlybefore incrementing the kswapd_failures, as it considers the overallmemory state acceptable, even though some zones (like ZONE_NORMAL) remainunder significant pressure.The patch ensures that zone_reclaimable_pages() includes free pages(NR_FREE_PAGES) in its calculation when no other reclaimable pages areavailable (e.g., file-backed or anonymous pages). This change preventszones like ZONE_DMA32, which have sufficient free pages, from beingmistakenly deemed unreclaimable. By doing so, the patch ensures propernode balancing, avoids masking pressure on other zones like ZONE_NORMAL,and prevents infinite loops in throttle_direct_reclaim() caused byallow_direct_reclaim(pgdat) repeatedly returning false.The kernel hangs due to a task stuck in throttle_direct_reclaim(), causedby a node being incorrectly deemed balanced despite pressure in certainzones, such as ZONE_NORMAL. This issue arises fromzone_reclaimable_pages---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM workerAfter commit746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")amdgpu started seeing the following warning: [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu]... [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched]... [ ] Call Trace: [ ] ... [ ] ? check_flush_dependency+0xf5/0x110... [ ] cancel_delayed_work_sync+0x6e/0x80 [ ] amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu] [ ] amdgpu_ring_alloc+0x40/0x50 [amdgpu] [ ] amdgpu_ib_schedule+0xf4/0x810 [amdgpu] [ ] ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched] [ ] amdgpu_job_run+0xaa/0x1f0 [amdgpu] [ ] drm_sched_run_job_work+0x257/0x430 [gpu_sched] [ ] process_one_work+0x217/0x720... [ ] The intent of the verifcation done in check_flush_depedency is to ensureforward progress during memory reclaim, by flagging cases when either amemory reclaim process, or a memory reclaim work item is flushed from acontext not marked as memory reclaim safe.This is correct when flushing, but when called from thecancel(_delayed)_work_sync() paths it is a false positive because work iseither already running, or will not be running at all. Thereforecancelling it is safe and we can relax the warning criteria by letting thehelper know of the calling context.References: 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: mcp23s08: Fix sleeping in atomic context due to regmap lockingIf a device uses MCP23xxx IO expander to receive IRQs, the followingbug can happen: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ... preempt_count: 1, expected: 0 ... Call Trace: ... __might_resched+0x104/0x10e __might_sleep+0x3e/0x62 mutex_lock+0x20/0x4c regmap_lock_mutex+0x10/0x18 regmap_update_bits_base+0x2c/0x66 mcp23s08_irq_set_type+0x1ae/0x1d6 __irq_set_trigger+0x56/0x172 __setup_irq+0x1e6/0x646 request_threaded_irq+0xb6/0x160 ...We observed the problem while experimenting with a touchscreen driver whichused MCP23017 IO expander (I2C).The regmap in the pinctrl-mcp23s08 driver uses a mutex for protection fromconcurrent accesses, which is the default for regmaps without .fast_io,.disable_locking, etc.mcp23s08_irq_set_type() calls regmap_update_bits_base(), and the latterlocks the mutex.However, __setup_irq() locks desc->lock spinlock before calling thesefunctions. As a result, the system tries to lock the mutex whole holdingthe spinlock.It seems, the internal regmap locks are not needed in this driver at all.mcp->lock seems to protect the regmap from concurrent accesses already,except, probably, in mcp_pinconf_get/set.mcp23s08_irq_set_type() and mcp23s08_irq_mask/unmask() are called underchip_bus_lock(), which calls mcp23s08_irq_bus_lock(). The latter takesmcp->lock and enables regmap caching, so that the potentially slow I2Caccesses are deferred until chip_bus_unlock().The accesses to the regmap from mcp23s08_probe_one() do not need additionallocking.In all remaining places where the regmap is accessed, exceptmcp_pinconf_get/set(), the driver already takes mcp->lock.This patch adds locking in mcp_pinconf_get/set() and disables internallocking in the regmap config. Among other things, it fixes the sleepingin atomic context described above.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix slab-use-after-free due to dangling pointer dqi_privWhen mounting ocfs2 and then remounting it as read-only, aslab-use-after-free occurs after the user uses a syscall toquota_getnextquota. Specifically, sb_dqinfo(sb, type)->dqi_priv is thedangling pointer.During the remounting process, the pointer dqi_priv is freed but is neverset as null leaving it to be accessed. Additionally, the read-only optionfor remounting sets the DQUOT_SUSPENDED flag instead of setting theDQUOT_USAGE_ENABLED flags. Moreover, later in the process of getting thenext quota, the function ocfs2_get_next_id is called and only checks thequota usage flags and not the quota suspended flags.To fix this, I set dqi_priv to null when it is freed after remounting withread-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.[akpm@linux-foundation.org: coding-style cleanups]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: flush delalloc workers queue before stopping cleaner kthread during unmountDuring the unmount path, at close_ctree(), we first stop the cleanerkthread, using kthread_stop() which frees the associated task_struct, andthen stop and destroy all the work queues. However after we stopped thecleaner we may still have a worker from the delalloc_workers queue runninginode.c:submit_compressed_extents(), which calls btrfs_add_delayed_iput(),which in turn tries to wake up the cleaner kthread - which was alreadydestroyed before, resulting in a use-after-free on the task_struct.Syzbot reported this with the following stack traces: BUG: KASAN: slab-use-after-free in __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 Read of size 8 at addr ffff8880259d2818 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.13.0-rc1-syzkaller-00002-gcdd30ebb1b9f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-delalloc btrfs_work_helper Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xc2/0x1470 kernel/sched/core.c:4205 submit_compressed_extents+0xdf/0x16e0 fs/btrfs/inode.c:1615 run_ordered_work fs/btrfs/async-thread.c:288 [inline] btrfs_work_helper+0x96f/0xc40 fs/btrfs/async-thread.c:324 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:250 [inline] slab_post_alloc_hook mm/slub.c:4104 [inline] slab_alloc_node mm/slub.c:4153 [inline] kmem_cache_alloc_node_noprof+0x1d9/0x380 mm/slub.c:4205 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1113 copy_process+0x5d1/0x3d50 kernel/fork.c:2225 kernel_clone+0x223/0x870 kernel/fork.c:2807 kernel_thread+0x1bc/0x240 kernel/fork.c:2869 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:767 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 24: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2338 [inline] slab_free mm/slub.c:4598 [inline] kmem_cache_free+0x195/0x410 mm/slub.c:4700 put_task_struct include/linux/sched/task.h:144 [inline] delayed_put_task_struct+0x125/0x300 kernel/exit.c:227 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:943 ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: restrict SO_REUSEPORT to inet socketsAfter blamed commit, crypto sockets could accidentally be destroyedfrom RCU call back, as spotted by zyzbot [1].Trying to acquire a mutex in RCU callback is not allowed.Restrict SO_REUSEPORT socket option to inet sockets.v1 of this patch supported TCP, UDP and SCTP sockets,but fcnal-test.sh test needed RAW and ICMP support.[1]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:562in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24, name: ksoftirqd/1preempt_count: 100, expected: 0RCU nest depth: 0, expected: 01 lock held by ksoftirqd/1/24: #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2561 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823Preemption disabled at: [] softirq_handle_begin kernel/softirq.c:402 [inline] [] handle_softirqs+0x128/0x9b0 kernel/softirq.c:537CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.13.0-rc3-syzkaller-00174-ga024e377efed #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 __might_resched+0x5d4/0x780 kernel/sched/core.c:8758 __mutex_lock_common kernel/locking/mutex.c:562 [inline] __mutex_lock+0x131/0xee0 kernel/locking/mutex.c:735 crypto_put_default_null_skcipher+0x18/0x70 crypto/crypto_null.c:179 aead_release+0x3d/0x50 crypto/algif_aead.c:489 alg_do_release crypto/af_alg.c:118 [inline] alg_sock_destruct+0x86/0xc0 crypto/af_alg.c:502 __sk_destruct+0x58/0x5f0 net/core/sock.c:2260 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 run_ksoftirqd+0xca/0x130 kernel/softirq.c:950 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add check for granularity in dml ceil/floor helpers[Why]Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2()should check for granularity is non zero to avoid assert anddivide-by-zero error in dcn_bw_ functions.[How]Add check for granularity 0.(cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: relax assertions on failure to encode file handlesEncoding file handles is usually performed by a filesystem >encode_fh()method that may fail for various reasons.The legacy users of exportfs_encode_fh(), namely, nfsd andname_to_handle_at(2) syscall are ready to cope with the possibilityof failure to encode a file handle.There are a few other users of exportfs_encode_{fh,fid}() thatcurrently have a WARN_ON() assertion when ->encode_fh() fails.Relax those assertions because they are wrong.The second linked bug report states commit 16aac5ad1fa9 ("ovl: supportencoding non-decodable file handles") in v6.6 as the regressing commit,but this is not accurate.The aforementioned commit only increases the chances of the assertionand allows triggering the assertion with the reproducer using overlayfs,inotify and drop_caches.Triggering this assertion was always possible with other filesystems andother reasons of ->encode_fh() failures and more particularly, it wasalso possible with the exact same reproducer using overlayfs that ismounted with options index=on,nfs_export=on also on kernels < v6.6.Therefore, I am not listing the aforementioned commit as a Fixes commit.Backport hint: this patch will have a trivial conflict applying tov6.6.y, and other trivial conflicts applying to stable kernels < v6.6.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:selinux: ignore unknown extended permissionsWhen evaluating extended permissions, ignore unknown permissions insteadof calling BUG(). This commit ensures that future permissions can beadded without interfering with older kernels.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: guard XDP xmit NDO on existence of xdp queuesIn GVE, dedicated XDP queues only exist when an XDP program is installedand the interface is up. As such, the NDO XDP XMIT callback shouldreturn early if either of these conditions are false.In the case of no loaded XDP program, priv->num_xdp_queues=0 which cancause a divide-by-zero error, and in the case of interface down,num_xdp_queues remains untouched to persist XDP queue count for the nextinterface up, but the TX pointer itself would be NULL.The XDP xmit callback also needs to synchronize with a devicetransitioning from open to close. This synchronization will happen viathe GVE_PRIV_FLAGS_NAPI_ENABLED bit along with a synchronize_net() call,which waits for any RCU critical sections at call-time to complete.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: guard XSK operations on the existence of queuesThis patch predicates the enabling and disabling of XSK pools on theexistence of queues. As it stands, if the interface is down, disablingor enabling XSK pools would result in a crash, as the RX queue pointerwould be NULL. XSK pool registration will occur as part of the nextinterface up.Similarly, xsk_wakeup needs be guarded against queues disappearingwhile the function is executing, so a check against theGVE_PRIV_FLAGS_NAPI_ENABLED flag is added to synchronize with thedisabling of the bit and the synchronize_net() in gve_turndown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix accessing invalid dip_ctx during destroying QPIf it fails to modify QP to RTR, dip_ctx will not be attached. Andduring detroying QP, the invalid dip_ctx pointer will be accessed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sctp: Prevent autoclose integer overflow in sctp_association_init()While by default max_autoclose equals to INT_MAX / HZ, one may setnet.sctp.max_autoclose to UINT_MAX. There is code insctp_association_init() that can consequently trigger overflow.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio-blk: don't keep queue frozen during system suspendCommit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues beforedeleting vqs.") replaces queue quiesce with queue freeze in virtio-blk'sPM callbacks. And the motivation is to drain inflight IOs before suspending.block layer's queue freeze looks very handy, but it is also easy to causedeadlock, such as, any attempt to call into bio_queue_enter() may run intodeadlock if the queue is frozen in current context. There are all kindsof ->suspend() called in suspend context, so keeping queue frozen in thewhole suspend context isn't one good idea. And Marek reported lockdepwarning[1] caused by virtio-blk's freeze queue in virtblk_freeze().[1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/Given the motivation is to drain in-flight IOs, it can be done by callingfreeze & unfreeze, meantime restore to previous behavior by keeping queuequiesced during suspend.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Remove dangling pointersWhen an async control is written, we copy a pointer to the file handlethat started the operation. That pointer will be used when the device isdone. Which could be anytime in the future.If the user closes that file descriptor, its structure will be freed,and there will be one dangling pointer per pending async control, thatthe driver will try to use.Clean all the dangling pointers during release().To avoid adding a performance penalty in the most common case (no asyncoperation), a counter has been introduced with some logic to make surethat it is properly handled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: ds90ub9x3: Fix extra fwnode_handle_put()The ub913 and ub953 drivers call fwnode_handle_put(priv->sd.fwnode) aspart of their remove process, and if the driver is removed multipletimes, eventually leads to put "overflow", possibly causing memorycorruption or crash.The fwnode_handle_put() is a leftover from commit 905f88ccebb1 ("media:i2c: ds90ub9x3: Fix sub-device matching"), which changed the coderelated to the sd.fwnode, but missed removing these fwnode_handle_put()calls.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: intel/ipu6: remove cpu latency qos request on errorFix cpu latency qos list corruption like below. It happens whenwe do not remove cpu latency request on error path and freecorresponding memory.[ 30.634378] l7 kernel: list_add corruption. prev->next should be next (ffffffff9645e960), but was 0000000100100001. (prev=ffff8e9e877e20a8).[ 30.634388] l7 kernel: WARNING: CPU: 2 PID: 2008 at lib/list_debug.c:32 __list_add_valid_or_report+0x83/0xa0[ 30.634640] l7 kernel: Call Trace:[ 30.634650] l7 kernel: [ 30.634659] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0[ 30.634669] l7 kernel: ? __warn.cold+0x93/0xf6[ 30.634678] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0[ 30.634690] l7 kernel: ? report_bug+0xff/0x140[ 30.634702] l7 kernel: ? handle_bug+0x58/0x90[ 30.634712] l7 kernel: ? exc_invalid_op+0x17/0x70[ 30.634723] l7 kernel: ? asm_exc_invalid_op+0x1a/0x20[ 30.634733] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0[ 30.634742] l7 kernel: plist_add+0xdd/0x140[ 30.634754] l7 kernel: pm_qos_update_target+0xa0/0x1f0[ 30.634764] l7 kernel: cpu_latency_qos_update_request+0x61/0xc0[ 30.634773] l7 kernel: intel_dp_aux_xfer+0x4c7/0x6e0 [i915 1f824655ed04687c2b0d23dbce759fa785f6d033]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: Change to kvalloc() in eventlog/acpi.cThe following failure was reported on HPE ProLiant D320:[ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0)[ 10.848132][ T1] ------------[ cut here ]------------[ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330[ 10.862827][ T1] Modules linked in:[ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375[ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024[ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330[ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1[ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246[ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000[ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0The above transcript shows that ACPI pointed a 16 MiB buffer for the logevents because RSI maps to the 'order' parameter of __alloc_pages_noprof().Address the bug by moving from devm_kmalloc() to devm_add_action() andkvmalloc() and devm_add_action().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() updateinbound map address") set_bar() was modified to support dynamicallychanging the backing physical address of a BAR that was already configured.This means that set_bar() can be called twice, without ever callingclear_bar() (as calling clear_bar() would clear the BAR's PCI addressassigned by the host).This can only be done if the new BAR size/flags does not differ from theexisting BAR configuration. Add these missing checks.If we allow set_bar() to set e.g. a new BAR size that differs from theexisting BAR size, the new address translation range will be smaller thanthe BAR size already determined by the host, which would mean that a readpast the new BAR size would pass the iATU untranslated, which could allowthe host to read memory not belonging to the new struct pci_epf_bar.While at it, add comments which clarifies the support for dynamicallychanging the physical address of a BAR. (Which was also missing.)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: socinfo: Avoid out of bounds read of serial numberOn MSM8916 devices, the serial number exposed in sysfs is constant and doesnot change across individual devices. It's always: db410c:/sys/devices/soc0$ cat serial_number 2644893864The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does nothave support for the serial_num field in the socinfo struct. There is anexisting check to avoid exposing the serial number in that case, but it'snot correct: When checking the item_size returned by SMEM, we need to makesure the *end* of the serial_num is within bounds, instead of comparingwith the *start* offset. The serial_number currently exposed on MSM8916devices is just an out of bounds read of whatever comes after the socinfostruct in SMEM.Fix this by changing offsetof() to offsetofend(), so that the size of thefield is also taken into account.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KEYS: trusted: dcp: fix improper sg use with CONFIG_VMAP_STACK=yWith vmalloc stack addresses enabled (CONFIG_VMAP_STACK=y) DCP trustedkeys can crash during en- and decryption of the blob encryption key viathe DCP crypto driver. This is caused by improperly using sg_init_one()with vmalloc'd stack buffers (plain_key_blob).Fix this by always using kmalloc() for buffers we give to the DCP cryptodriver.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_allocA NULL sock pointer is passed into l2cap_sock_alloc() when it is calledfrom l2cap_sock_new_connection_cb() and the error handling paths shouldalso be aware of it.Seemingly a more elegant solution would be to swap bt_sock_alloc() andl2cap_chan_create() calls since they are not interdependent to that momentbut then l2cap_chan_create() adds the soon to be deallocated and stilldummy-initialized channel to the global list accessible by many L2CAPpaths. The channel would be removed from the list in short period of timebut be a bit more straight-forward here and just check for NULL instead ofchanging the order of function calls.Found by Linux Verification Center (linuxtesting.org) with SVACE staticanalysis tool.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: int3472: Check for adev == NULLNot all devices have an ACPI companion fwnode, so adev might be NULL. Thiscan e.g. (theoretically) happen when a user manually binds one ofthe int3472 drivers to another i2c/platform device through sysfs.Add a check for adev not being set and return -ENODEV in that case toavoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Fix for out-of bound access errorSelfgen stats are placed in a buffer using print_array_to_buf_index() function.Array length parameter passed to the function is too big, resulting in possibleout-of bound memory error.Decreasing buffer size by one fixes faulty upper bound of passed array.Discovered in coverity scan, CID 1600742 and CID 1600758
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvkm: correctly calculate the available space of the GSP cmdq bufferr535_gsp_cmdq_push() waits for the available page in the GSP cmdqbuffer when handling a large RPC request. When it sees at least oneavailable page in the cmdq, it quits the waiting with the amount offree buffer pages in the queue.Unfortunately, it always takes the [write pointer, buf_size) asavailable buffer pages before rolling back and wrongly calculates thesize of the data should be copied. Thus, it can overwrite the RPCrequest that GSP is currently reading, which causes GSP hang dueto corrupted RPC request:[ 549.209389] ------------[ cut here ]------------[ 549.214010] WARNING: CPU: 8 PID: 6314 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:116 r535_gsp_msgq_wait+0xd0/0x190 [nvkm][ 549.225678] Modules linked in: nvkm(E+) gsp_log(E) snd_seq_dummy(E) snd_hrtimer(E) snd_seq(E) snd_timer(E) snd_seq_device(E) snd(E) soundcore(E) rfkill(E) qrtr(E) vfat(E) fat(E) ipmi_ssif(E) amd_atl(E) intel_rapl_msr(E) intel_rapl_common(E) mlx5_ib(E) amd64_edac(E) edac_mce_amd(E) kvm_amd(E) ib_uverbs(E) kvm(E) ib_core(E) acpi_ipmi(E) ipmi_si(E) mxm_wmi(E) ipmi_devintf(E) rapl(E) i2c_piix4(E) wmi_bmof(E) joydev(E) ptdma(E) acpi_cpufreq(E) k10temp(E) pcspkr(E) ipmi_msghandler(E) xfs(E) libcrc32c(E) ast(E) i2c_algo_bit(E) crct10dif_pclmul(E) drm_shmem_helper(E) nvme_tcp(E) crc32_pclmul(E) ahci(E) drm_kms_helper(E) libahci(E) nvme_fabrics(E) crc32c_intel(E) nvme(E) cdc_ether(E) mlx5_core(E) nvme_core(E) usbnet(E) drm(E) libata(E) ccp(E) ghash_clmulni_intel(E) mii(E) t10_pi(E) mlxfw(E) sp5100_tco(E) psample(E) pci_hyperv_intf(E) wmi(E) dm_multipath(E) sunrpc(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E) be2iscsi(E) bnx2i(E) cnic(E) uio(E) cxgb4i(E) cxgb4(E) tls(E) libcxgbi(E) libcxgb(E) qla4xxx(E)[ 549.225752] iscsi_boot_sysfs(E) iscsi_tcp(E) libiscsi_tcp(E) libiscsi(E) scsi_transport_iscsi(E) fuse(E) [last unloaded: gsp_log(E)][ 549.326293] CPU: 8 PID: 6314 Comm: insmod Tainted: G E 6.9.0-rc6+ #1[ 549.334039] Hardware name: ASRockRack 1U1G-MILAN/N/ROMED8-NL, BIOS L3.12E 09/06/2022[ 549.341781] RIP: 0010:r535_gsp_msgq_wait+0xd0/0x190 [nvkm][ 549.347343] Code: 08 00 00 89 da c1 e2 0c 48 8d ac 11 00 10 00 00 48 8b 0c 24 48 85 c9 74 1f c1 e0 0c 4c 8d 6d 30 83 e8 30 89 01 e9 68 ff ff ff <0f> 0b 49 c7 c5 92 ff ff ff e9 5a ff ff ff ba ff ff ff ff be c0 0c[ 549.366090] RSP: 0018:ffffacbccaaeb7d0 EFLAGS: 00010246[ 549.371315] RAX: 0000000000000000 RBX: 0000000000000012 RCX: 0000000000923e28[ 549.378451] RDX: 0000000000000000 RSI: 0000000055555554 RDI: ffffacbccaaeb730[ 549.385590] RBP: 0000000000000001 R08: ffff8bd14d235f70 R09: ffff8bd14d235f70[ 549.392721] R10: 0000000000000002 R11: ffff8bd14d233864 R12: 0000000000000020[ 549.399854] R13: ffffacbccaaeb818 R14: 0000000000000020 R15: ffff8bb298c67000[ 549.406988] FS: 00007f5179244740(0000) GS:ffff8bd14d200000(0000) knlGS:0000000000000000[ 549.415076] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 549.420829] CR2: 00007fa844000010 CR3: 00000001567dc005 CR4: 0000000000770ef0[ 549.427963] PKRU: 55555554[ 549.430672] Call Trace:[ 549.433126] [ 549.435233] ? __warn+0x7f/0x130[ 549.438473] ? r535_gsp_msgq_wait+0xd0/0x190 [nvkm][ 549.443426] ? report_bug+0x18a/0x1a0[ 549.447098] ? handle_bug+0x3c/0x70[ 549.450589] ? exc_invalid_op+0x14/0x70[ 549.454430] ? asm_exc_invalid_op+0x16/0x20[ 549.458619] ? r535_gsp_msgq_wait+0xd0/0x190 [nvkm][ 549.463565] r535_gsp_msg_recv+0x46/0x230 [nvkm][ 549.468257] r535_gsp_rpc_push+0x106/0x160 [nvkm][ 549.473033] r535_gsp_rpc_rm_ctrl_push+0x40/0x130 [nvkm][ 549.478422] nvidia_grid_init_vgpu_types+0xbc/0xe0 [nvkm][ 549.483899] nvidia_grid_init+0xb1/0xd0 [nvkm][ 549.488420] ? srso_alias_return_thunk+0x5/0xfbef5[ 549.493213] nvkm_device_pci_probe+0x305/0x420 [nvkm][ 549.498338] local_pci_probe+0x46/---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvkm/gsp: correctly advance the read pointer of GSP message queueA GSP event message consists three parts: message header, RPC header,message body. GSP calculates the number of pages to write from thetotal size of a GSP message. This behavior can be observed from themovement of the write pointer.However, nvkm takes only the size of RPC header and message body asthe message size when advancing the read pointer. When handling atwo-page GSP message in the non rollback case, It wrongly takes themessage body of the previous message as the message header of the nextmessage. As the "message length" tends to be zero, in the calculation ofsize needs to be copied (0 - size of (message header)), the size needs tobe copied will be "0xffffffxx". It also triggers a kernel panic due to aNULL pointer error.[ 547.614102] msg: 00000f90: ff ff ff ff ff ff ff ff 40 d7 18 fb 8b 00 00 00 ........@.......[ 547.622533] msg: 00000fa0: 00 00 00 00 ff ff ff ff ff ff ff ff 00 00 00 00 ................[ 547.630965] msg: 00000fb0: ff ff ff ff ff ff ff ff 00 00 00 00 ff ff ff ff ................[ 547.639397] msg: 00000fc0: ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff ................[ 547.647832] nvkm 0000:c1:00.0: gsp: peek msg rpc fn:0 len:0x0/0xffffffffffffffe0[ 547.655225] nvkm 0000:c1:00.0: gsp: get msg rpc fn:0 len:0x0/0xffffffffffffffe0[ 547.662532] BUG: kernel NULL pointer dereference, address: 0000000000000020[ 547.669485] #PF: supervisor read access in kernel mode[ 547.674624] #PF: error_code(0x0000) - not-present page[ 547.679755] PGD 0 P4D 0[ 547.682294] Oops: 0000 [#1] PREEMPT SMP NOPTI[ 547.686643] CPU: 22 PID: 322 Comm: kworker/22:1 Tainted: G E 6.9.0-rc6+ #1[ 547.694893] Hardware name: ASRockRack 1U1G-MILAN/N/ROMED8-NL, BIOS L3.12E 09/06/2022[ 547.702626] Workqueue: events r535_gsp_msgq_work [nvkm][ 547.707921] RIP: 0010:r535_gsp_msg_recv+0x87/0x230 [nvkm][ 547.713375] Code: 00 8b 70 08 48 89 e1 31 d2 4c 89 f7 e8 12 f5 ff ff 48 89 c5 48 85 c0 0f 84 cf 00 00 00 48 81 fd 00 f0 ff ff 0f 87 c4 00 00 00 <8b> 55 10 41 8b 46 30 85 d2 0f 85 f6 00 00 00 83 f8 04 76 10 ba 05[ 547.732119] RSP: 0018:ffffabe440f87e10 EFLAGS: 00010203[ 547.737335] RAX: 0000000000000010 RBX: 0000000000000008 RCX: 000000000000003f[ 547.744461] RDX: 0000000000000000 RSI: ffffabe4480a8030 RDI: 0000000000000010[ 547.751585] RBP: 0000000000000010 R08: 0000000000000000 R09: ffffabe440f87bb0[ 547.758707] R10: ffffabe440f87dc8 R11: 0000000000000010 R12: 0000000000000000[ 547.765834] R13: 0000000000000000 R14: ffff9351df1e5000 R15: 0000000000000000[ 547.772958] FS: 0000000000000000(0000) GS:ffff93708eb00000(0000) knlGS:0000000000000000[ 547.781035] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 547.786771] CR2: 0000000000000020 CR3: 00000003cc220002 CR4: 0000000000770ef0[ 547.793896] PKRU: 55555554[ 547.796600] Call Trace:[ 547.799046] [ 547.801152] ? __die+0x20/0x70[ 547.804211] ? page_fault_oops+0x75/0x170[ 547.808221] ? print_hex_dump+0x100/0x160[ 547.812226] ? exc_page_fault+0x64/0x150[ 547.816152] ? asm_exc_page_fault+0x22/0x30[ 547.820341] ? r535_gsp_msg_recv+0x87/0x230 [nvkm][ 547.825184] r535_gsp_msgq_work+0x42/0x50 [nvkm][ 547.829845] process_one_work+0x196/0x3d0[ 547.833861] worker_thread+0x2fc/0x410[ 547.837613] ? __pfx_worker_thread+0x10/0x10[ 547.841885] kthread+0xdf/0x110[ 547.845031] ? __pfx_kthread+0x10/0x10[ 547.848775] ret_from_fork+0x30/0x50[ 547.852354] ? __pfx_kthread+0x10/0x10[ 547.856097] ret_from_fork_asm+0x1a/0x30[ 547.860019] [ 547.862208] Modules linked in: nvkm(E) gsp_log(E) snd_seq_dummy(E) snd_hrtimer(E) snd_seq(E) snd_timer(E) snd_seq_device(E) snd(E) soundcore(E) rfkill(E) qrtr(E) vfat(E) fat(E) ipmi_ssif(E) amd_atl(E) intel_rapl_msr(E) intel_rapl_common(E) amd64_edac(E) mlx5_ib(E) edac_mce_amd(E) kvm_amd---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: winwing: Add NULL check in winwing_init_led()devm_kasprintf() can return a NULL pointer on failure,but thisreturned value in winwing_init_led() is not checked.Add NULL check in winwing_init_led(), to handle kernel NULLpointer dereference error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: qcom: gcc-sm6350: Add missing parent_map for two clocksIf a clk_rcg2 has a parent, it should also have parent_map defined,otherwise we'll get a NULL pointer dereference when calling clk_set_ratelike the following: [ 3.388105] Call trace: [ 3.390664] qcom_find_src_index+0x3c/0x70 (P) [ 3.395301] qcom_find_src_index+0x1c/0x70 (L) [ 3.399934] _freq_tbl_determine_rate+0x48/0x100 [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28 [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4 [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300 [ 3.455886] clk_set_rate+0x38/0x14cAdd the parent_map property for two clocks where it's missing and alsoun-inline the parent_data as well to keep the matching parent_map andparent_data together.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:misc: misc_minor_alloc to use ida for all dynamic/misc dynamic minorsmisc_minor_alloc was allocating id using ida for minor only in case ofMISC_DYNAMIC_MINOR but misc_minor_free was always freeing idsusing ida_free causing a mismatch and following warn:> > WARNING: CPU: 0 PID: 159 at lib/idr.c:525 ida_free+0x3e0/0x41f> > ida_free called for id=127 which is not allocated.> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<...> > [<60941eb4>] ida_free+0x3e0/0x41f> > [<605ac993>] misc_minor_free+0x3e/0xbc> > [<605acb82>] misc_deregister+0x171/0x1b3misc_minor_alloc is changed to allocate id from ida for all minorsfalling in the range of dynamic/ misc dynamic minors
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Fix crash during unbind if gpio unit is in useWe used the wrong device for the device managed functions. We used theusb device, when we should be using the interface device.If we unbind the driver from the usb interface, the cleanup functionsare never called. In our case, the IRQ is never disabled.If an IRQ is triggered, it will try to access memory sections that arealready free, causing an OOPS.We cannot use the function devm_request_threaded_irq here. The devm_*clean functions may be called after the main structure is released byuvc_delete.Luckily this bug has small impact, as it is only affected by deviceswith gpio units and the user has to unbind the device, a disconnect willnot trigger this error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: qcom: dispcc-sm6350: Add missing parent_map for a clockIf a clk_rcg2 has a parent, it should also have parent_map defined,otherwise we'll get a NULL pointer dereference when calling clk_set_ratelike the following: [ 3.388105] Call trace: [ 3.390664] qcom_find_src_index+0x3c/0x70 (P) [ 3.395301] qcom_find_src_index+0x1c/0x70 (L) [ 3.399934] _freq_tbl_determine_rate+0x48/0x100 [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28 [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4 [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300 [ 3.455886] clk_set_rate+0x38/0x14cAdd the parent_map property for the clock where it's missing and alsoun-inline the parent_data as well to keep the matching parent_map andparent_data together.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: mmp2: call pm_genpd_init() only after genpd.name is setSetting the genpd's struct device's name with dev_set_name() ishappening within pm_genpd_init(). If it remains NULL, things can blow uplater, such as when crafting the devfs hierarchy for the power domain: Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read ... Call trace: strlen from start_creating+0x90/0x138 start_creating from debugfs_create_dir+0x20/0x178 debugfs_create_dir from genpd_debug_add.part.0+0x4c/0x144 genpd_debug_add.part.0 from genpd_debug_init+0x74/0x90 genpd_debug_init from do_one_initcall+0x5c/0x244 do_one_initcall from kernel_init_freeable+0x19c/0x1f4 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x28Bisecting tracks this crash back to commit 899f44531fe6 ("pmdomain: core:Add GENPD_FLAG_DEV_NAME_FW flag"), which exchanges use of genpd->namewith dev_name(&genpd->dev) in genpd_debug_add.part().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: nuvoton: Fix an error check in npcm_video_ece_init()When function of_find_device_by_node() fails, it returns NULL instead ofan error code. So the corresponding error check logic should be modifiedto check whether the return value is NULL and set the error code to bereturned as -ENODEV.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()Explicitly verify the target vCPU is fully online _prior_ to clamping theindex in kvm_get_vcpu(). If the index is "bad", the nospec clamping willgenerate '0', i.e. KVM will return vCPU0 instead of NULL.In practice, the bug is unlikely to cause problems, as it will only comeinto play if userspace or the guest is buggy or misbehaving, e.g. KVM maysend interrupts to vCPU0 instead of dropping them on the floor.However, returning vCPU0 when it shouldn't exist per online_vcpus isproblematic now that KVM uses an xarray for the vCPUs array, as KVM needsto insert into the xarray before publishing the vCPU to userspace (seecommit c5b077549136 ("KVM: Convert the kvm->vcpus array to a xarray")),i.e. before vCPU creation is guaranteed to succeed.As a result, incorrectly providing access to vCPU0 will trigger ause-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu()bails out of vCPU creation due to an error and frees vCPU0. Commitafb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, butin doing so introduced an unsolvable teardown conundrum. Preventingaccesses to vCPU0 before it's fully online will allow reverting commitafb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: qcom: scm: Fix missing read barrier in qcom_scm_get_tzmem_pool()Commit 2e4955167ec5 ("firmware: qcom: scm: Fix __scm and waitqcompletion variable initialization") introduced a write barrier in probefunction to store global '__scm' variable. We all known barriers arepaired (see memory-barriers.txt: "Note that write barriers shouldnormally be paired with read or address-dependency barriers"), thereforeaccessing it from concurrent contexts requires read barrier. Previouscommit added such barrier in qcom_scm_is_available(), so let's use thatdirectly.Lack of this read barrier can result in fetching stale '__scm' variablevalue, NULL, and dereferencing it.Note that barrier in qcom_scm_is_available() satisfies here the controldependency.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Stop active perfmon if it is being destroyedIf the active performance monitor (`v3d->active_perfmon`) is beingdestroyed, stop it first. Currently, the active perfmon is notstopped during destruction, leaving the `v3d->active_perfmon` pointerstale. This can lead to undefined behavior and instability.This patch ensures that the active perfmon is stopped before beingdestroyed, aligning with the behavior introduced in commit7d1fd3638ee3 ("drm/v3d: Stop the active perfmon before being destroyed").
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix double accounting race when btrfs_run_delalloc_range() failed[BUG]When running btrfs with block size (4K) smaller than page size (64K,aarch64), there is a very high chance to crash the kernel atgeneric/750, with the following messages:(before the call traces, there are 3 extra debug messages added) BTRFS warning (device dm-3): read-write for sector size 4096 with page size 65536 is experimental BTRFS info (device dm-3): checking UUID tree hrtimer: interrupt took 5451385 ns BTRFS error (device dm-3): cow_file_range failed, root=4957 inode=257 start=1605632 len=69632: -28 BTRFS error (device dm-3): run_delalloc_nocow failed, root=4957 inode=257 start=1605632 len=69632: -28 BTRFS error (device dm-3): failed to run delalloc range, root=4957 ino=257 folio=1572864 submit_bitmap=8-15 start=1605632 len=69632: -28 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 3020984 at ordered-data.c:360 can_finish_ordered_extent+0x370/0x3b8 [btrfs] CPU: 2 UID: 0 PID: 3020984 Comm: kworker/u24:1 Tainted: G OE 6.13.0-rc1-custom+ #89 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : can_finish_ordered_extent+0x370/0x3b8 [btrfs] lr : can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] Call trace: can_finish_ordered_extent+0x370/0x3b8 [btrfs] (P) can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] (L) btrfs_mark_ordered_io_finished+0x130/0x2b8 [btrfs] extent_writepage+0x10c/0x3b8 [btrfs] extent_write_cache_pages+0x21c/0x4e8 [btrfs] btrfs_writepages+0x94/0x160 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x74/0xa0 start_delalloc_inodes+0x17c/0x3b0 [btrfs] btrfs_start_delalloc_roots+0x17c/0x288 [btrfs] shrink_delalloc+0x11c/0x280 [btrfs] flush_space+0x288/0x328 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x228/0x680 worker_thread+0x1bc/0x360 kthread+0x100/0x118 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1605632 OE len=16384 to_dec=16384 left=0 BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1622016 OE len=12288 to_dec=12288 left=0 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1634304 OE len=8192 to_dec=4096 left=0 CPU: 1 UID: 0 PID: 3286940 Comm: kworker/u24:3 Tainted: G W OE 6.13.0-rc1-custom+ #89 Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: btrfs_work_helper [btrfs] (btrfs-endio-write) pstate: 404000c5 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : process_one_work+0x110/0x680 lr : worker_thread+0x1bc/0x360 Call trace: process_one_work+0x110/0x680 (P) worker_thread+0x1bc/0x360 (L) worker_thread+0x1bc/0x360 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: f84086a1 f9000fe1 53041c21 b9003361 (f9400661) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception SMP: stopping secondary CPUs SMP: failed to stop secondary CPUs 2-3 Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: 0x275bb9540000 from 0xffff800080000000 PHYS_OFFSET: 0xffff8fbba0000000 CPU features: 0x100,00000070,00801250,8201720b[CAUSE]The above warning is triggered immediately after the delalloc rangefailure, this happens in the following sequence:- Range [1568K, 1636K) is dirty 1536K 1568K 1600K 1636K 1664K | |/////////|////////| | Where 1536K, 1600K and 1664K are page boundaries (64K page size)- Enter extent_writepage() for page 1536K- Enter run_delalloc_nocow() with locke---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/core: Prevent rescheduling when interrupts are disabledDavid reported a warning observed while loop testing kexec jump: Interrupts enabled after irqrouter_resume+0x0/0x50 WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180The corresponding interrupt flag trace: hardirqs last enabled at (15573): [] __up_console_sem+0x7e/0x90 hardirqs last disabled at (15580): [] __up_console_sem+0x63/0x90That means __up_console_sem() was invoked with interrupts enabled. Furtherinstrumentation revealed that in the interrupt disabled section of kexecjump one of the syscore_suspend() callbacks woke up a task, which set theNEED_RESCHED flag. A later callback in the resume path invokedcond_resched() which in turn led to the invocation of the scheduler: __cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180This is a long standing problem, which probably got more visible withthe recent printk changes. Something does a task wakeup and thescheduler sets the NEED_RESCHED flag. cond_resched() sees it set andinvokes schedule() from a completely bogus context. The schedulerenables interrupts after context switching, which causes the abovewarning at the end.Quite some of the code paths in syscore_suspend()/resume() can result intriggering a wakeup with the exactly same consequences. They might nothave done so yet, but as they share a lot of code with normal operationsit's just a question of time.The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY schedulingmodels. Full preemption is not affected as cond_resched() is disabled andthe preemption check preemptible() takes the interrupt disabled flag intoaccount.Cure the problem by adding a corresponding check into cond_resched().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/fbdev-dma: Add shadow buffering for deferred I/ODMA areas are not necessarily backed by struct page, so we cannotrely on it for deferred I/O. Allocate a shadow buffer for driversthat require deferred I/O and use it as framebuffer memory.Fixes driver errors about being "Unable to handle kernel NULL pointerdereference at virtual address" or "Unable to handle kernel pagingrequest at virtual address".The patch splits drm_fbdev_dma_driver_fbdev_probe() in an initialallocation, which creates the DMA-backed buffer object, and a tailthat sets up the fbdev data structures. There is a tail function fordirect memory mappings and a tail function for deferred I/O withthe shadow buffer.It is no longer possible to use deferred I/O without shadow buffer.It can be re-added if there exists a reliably test for usable structpage in the allocated DMA-backed buffer object.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Fix link state exit during switch upstream function removalBefore 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal toavoid use-after-free"), we would free the ASPM link only after the lastfunction on the bus pertaining to the given link was removed.That was too late. If function 0 is removed before sibling function,link->downstream would point to free'd memory after.After above change, we freed the ASPM parent link state upon any functionremoval on the bus pertaining to a given link.That is too early. If the link is to a PCIe switch with MFD on the upstreamport, then removing functions other than 0 first would free a link whichstill remains parent_link to the remaining downstream ports.The resulting GPFs are especially frequent during hot-unplug, becausepciehp removes devices on the link bus in reverse order.On that switch, function 0 is the virtual P2P bridge to the internal bus.Free exactly when function 0 is removed -- before the parent link isobsolete, but after all subordinate links are gone.[kwilczynski: commit log]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix RCU stall while reaping monitor destination ringWhile processing the monitor destination ring, MSDUs are reaped from thelink descriptor based on the corresponding buf_id.However, sometimes the driver cannot obtain a valid buffer correspondingto the buf_id received from the hardware. This causes an infinite loopin the destination processing, resulting in a kernel crash.kernel log:ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failedath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failedFix this by skipping the problematic buf_id and reaping the next entry,replacing the break with the next MSDU processing.Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The per-netns structure can be obtained from the table->data usingcontainer_of(), then the 'net' one can be retrieved from the listensocket (if available).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: plpmtud_probe_interval: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.probe_interval' isused.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: udp_port: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, but that wouldincrease the size of this fix, while 'sctp.ctl_sock' still needs to beretrieved from 'net' structure.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: auth_enable: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, but that wouldincrease the size of this fix, while 'sctp.ctl_sock' still needs to beretrieved from 'net' structure.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: rto_min/max: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.rto_min/max' is used.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: cookie_hmac_alg: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.sctp_hmac_alg' isused.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled itWakeup for IRQ1 should be disabled only in cases where i8042 hadactually enabled it, otherwise "wake_depth" for this IRQ will try todrop below zero and there will be an unpleasant WARN() logged:kernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bugkernel: ------------[ cut here ]------------kernel: Unbalanced IRQ 1 wake disablekernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irq_set_irq_wake+0x147/0x1a0The PMC driver uses DEFINE_SIMPLE_DEV_PM_OPS() to define its dev_pm_opswhich sets amd_pmc_suspend_handler() to the .suspend, .freeze, and.poweroff handlers. i8042_pm_suspend(), however, is only set asthe .suspend handler.Fix the issue by call PMC suspend handler only from the same set ofdev_pm_ops handlers as i8042_pm_suspend(), which currently means justthe .suspend handler.To reproduce this issue try hibernating (S4) the machine after a fresh bootwithout putting it into s2idle first.[ij: edited the commit message.]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:afs: Fix the maximum cell name lengthThe kafs filesystem limits the maximum length of a cell to 256 bytes, but aproblem occurs if someone actually does that: kafs tries to create adirectory under /proc/net/afs/ with the name of the cell, but that failswith a warning: WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405because procfs limits the maximum filename length to 255.However, the DNS limits the maximum lookup length and, by extension, themaximum cell name, to 255 less two (length count and trailing NUL).Fix this by limiting the maximum acceptable cellname length to 253. Thisalso allows us to be sure we can create the "/afs/.| /" mountpoint too.Further, split the YFS VL record cell name maximum to be the 256 allowed bythe protocol and ignore the record retrieved by YFSVL.GetCellName if itexceeds 253.
|
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash when 1588 is sent on HIP08 devicesCurrently, HIP08 devices does not register the ptp devices, so thehdev->ptp is NULL. But the tx process would still try to set hardware timestamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash.[ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018...[ 128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge][ 128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge][ 128.292938] sp : ffff800059b93140[ 128.297200] x29: ffff800059b93140 x28: 0000000000003280[ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080[ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001[ 128.315969] x23: 0000000000000000 x22: 0000000000000194[ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000[ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000[ 128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24[ 128.340934] x15: 0000ffffd530a518 x14: 0000000000000000[ 128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368[ 128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02[ 128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0[ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000[ 128.372040] x5 : 0000000000000000 x4 : 000000000000ffff[ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294[ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080[ 128.390626] Call trace:[ 128.393964] hclge_ptp_set_tx_info+0x2c/0x140 [hclge][ 128.399893] hns3_nic_net_xmit+0x39c/0x4c4 [hns3][ 128.405468] xmit_one.constprop.0+0xc4/0x200[ 128.410600] dev_hard_start_xmit+0x54/0xf0[ 128.415556] sch_direct_xmit+0xe8/0x634[ 128.420246] __dev_queue_xmit+0x224/0xc70[ 128.425101] dev_queue_xmit+0x1c/0x40[ 128.429608] ovs_vport_send+0xac/0x1a0 [openvswitch][ 128.435409] do_output+0x60/0x17c [openvswitch][ 128.440770] do_execute_actions+0x898/0x8c4 [openvswitch][ 128.446993] ovs_execute_actions+0x64/0xf0 [openvswitch][ 128.453129] ovs_dp_process_packet+0xa0/0x224 [openvswitch][ 128.459530] ovs_vport_receive+0x7c/0xfc [openvswitch][ 128.465497] internal_dev_xmit+0x34/0xb0 [openvswitch][ 128.471460] xmit_one.constprop.0+0xc4/0x200[ 128.476561] dev_hard_start_xmit+0x54/0xf0[ 128.481489] __dev_queue_xmit+0x968/0xc70[ 128.486330] dev_queue_xmit+0x1c/0x40[ 128.490856] ip_finish_output2+0x250/0x570[ 128.495810] __ip_finish_output+0x170/0x1e0[ 128.500832] ip_finish_output+0x3c/0xf0[ 128.505504] ip_output+0xbc/0x160[ 128.509654] ip_send_skb+0x58/0xd4[ 128.513892] udp_send_skb+0x12c/0x354[ 128.518387] udp_sendmsg+0x7a8/0x9c0[ 128.522793] inet_sendmsg+0x4c/0x8c[ 128.527116] __sock_sendmsg+0x48/0x80[ 128.531609] __sys_sendto+0x124/0x164[ 128.536099] __arm64_sys_sendto+0x30/0x5c[ 128.540935] invoke_syscall+0x50/0x130[ 128.545508] el0_svc_common.constprop.0+0x10c/0x124[ 128.551205] do_el0_svc+0x34/0xdc[ 128.555347] el0_svc+0x20/0x30[ 128.559227] el0_sync_handler+0xb8/0xc0[ 128.563883] el0_sync+0x160/0x180
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix variable not being completed when function returnsWhen cmd_alloc_index(), fails cmd_work_handler() needsto complete ent->slotted before returning early.Otherwise the task which issued the command may hang: mlx5_core 0000:01:00.0: cmd_work_handler:877:(pid 3880418): failed to allocate command entry INFO: task kworker/13:2:4055883 blocked for more than 120 seconds. Not tainted 4.19.90-25.44.v2101.ky10.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/13:2 D 0 4055883 2 0x00000228 Workqueue: events mlx5e_tx_dim_work [mlx5_core] Call trace: __switch_to+0xe8/0x150 __schedule+0x2a8/0x9b8 schedule+0x2c/0x88 schedule_timeout+0x204/0x478 wait_for_common+0x154/0x250 wait_for_completion+0x28/0x38 cmd_exec+0x7a0/0xa00 [mlx5_core] mlx5_cmd_exec+0x54/0x80 [mlx5_core] mlx5_core_modify_cq+0x6c/0x80 [mlx5_core] mlx5_core_modify_cq_moderation+0xa0/0xb8 [mlx5_core] mlx5e_tx_dim_work+0x54/0x68 [mlx5_core] process_one_work+0x1b0/0x448 worker_thread+0x54/0x468 kthread+0x134/0x138 ret_from_fork+0x10/0x18
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: dwmac-tegra: Read iommu stream id from device treeNvidia's Tegra MGBE controllers require the IOMMU "Stream ID" (SID) to bewritten to the MGBE_WRAP_AXI_ASID0_CTRL register.The current driver is hard coded to use MGBE0's SID for all controllers.This causes softirq time outs and kernel panics when using controllersother than MGBE0.Example dmesg errors when an ethernet cable is connected to MGBE1:[ 116.133290] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx[ 121.851283] tegra-mgbe 6910000.ethernet eth1: NETDEV WATCHDOG: CPU: 5: transmit queue 0 timed out 5690 ms[ 121.851782] tegra-mgbe 6910000.ethernet eth1: Reset adapter.[ 121.892464] tegra-mgbe 6910000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0[ 121.905920] tegra-mgbe 6910000.ethernet eth1: PHY [stmmac-1:00] driver [Aquantia AQR113] (irq=171)[ 121.907356] tegra-mgbe 6910000.ethernet eth1: Enabling Safety Features[ 121.907578] tegra-mgbe 6910000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported[ 121.908399] tegra-mgbe 6910000.ethernet eth1: registered PTP clock[ 121.908582] tegra-mgbe 6910000.ethernet eth1: configuring for phy/10gbase-r link mode[ 125.961292] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx[ 181.921198] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:[ 181.921404] rcu: 7-....: (1 GPs behind) idle=540c/1/0x4000000000000002 softirq=1748/1749 fqs=2337[ 181.921684] rcu: (detected by 4, t=6002 jiffies, g=1357, q=1254 ncpus=8)[ 181.921878] Sending NMI from CPU 4 to CPUs 7:[ 181.921886] NMI backtrace for cpu 7[ 181.922131] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: loaded Not tainted 6.13.0-rc3+ #6[ 181.922390] Hardware name: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 10/28/2024[ 181.922658] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 181.922847] pc : handle_softirqs+0x98/0x368[ 181.922978] lr : __do_softirq+0x18/0x20[ 181.923095] sp : ffff80008003bf50[ 181.923189] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000[ 181.923379] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0[ 181.924486] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70[ 181.925568] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000[ 181.926655] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000[ 181.931455] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d[ 181.938628] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160[ 181.945804] x8 : ffff8000827b3160 x7 : f9157b241586f343 x6 : eeb6502a01c81c74[ 181.953068] x5 : a4acfcdd2e8096bb x4 : ffffce78ea277340 x3 : 00000000ffffd1e1[ 181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000[ 181.967591] Call trace:[ 181.970043] handle_softirqs+0x98/0x368 (P)[ 181.974240] __do_softirq+0x18/0x20[ 181.977743] ____do_softirq+0x14/0x28[ 181.981415] call_on_irq_stack+0x24/0x30[ 181.985180] do_softirq_own_stack+0x20/0x30[ 181.989379] __irq_exit_rcu+0x114/0x140[ 181.993142] irq_exit_rcu+0x14/0x28[ 181.996816] el1_interrupt+0x44/0xb8[ 182.000316] el1h_64_irq_handler+0x14/0x20[ 182.004343] el1h_64_irq+0x80/0x88[ 182.007755] cpuidle_enter_state+0xc4/0x4a8 (P)[ 182.012305] cpuidle_enter+0x3c/0x58[ 182.015980] cpuidle_idle_call+0x128/0x1c0[ 182.020005] do_idle+0xe0/0xf0[ 182.023155] cpu_startup_entry+0x3c/0x48[ 182.026917] secondary_start_kernel+0xdc/0x120[ 182.031379] __secondary_switched+0x74/0x78[ 212.971162] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 7-.... } 6103 jiffies s: 417 root: 0x80/.[ 212.985935] rcu: blocking rcu_node structures (internal RCU debug):[ 212.992758] Sending NMI from CPU 0 to CPUs 7:[ 212.998539] NMI backtrace for cpu 7[ 213.004304] CPU: 7 UID: 0 PI---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:filemap: avoid truncating 64-bit offset to 32 bitsOn 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a64-bit value to 32 bits, leading to a possible infinite loop when writingto an xfs filesystem.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock: prevent null-ptr-deref in vsock_*[has_data|has_space]Recent reports have shown how we sometimes call vsock_*_has_data()when a vsock socket has been de-assigned from a transport (see attachedlinks), but we shouldn't.Previous commits should have solved the real problems, but we may havemore in the future, so to avoid null-ptr-deref, we can return 0(no space, no data available) but with a warning.This way the code should continue to run in a nearly consistent stateand have a warning that allows us to debug future problems.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Clear port select structure when fail to createClear the port select structure on error so no stale values left afterdefiners are destroyed. That's because the mlx5_lag_destroy_definers()always try to destroy all lag definers in the tt_map, so in the flowbelow lag definers get double-destroyed and cause kernel crash: mlx5_lag_port_sel_create() mlx5_lag_create_definers() mlx5_lag_create_definer() <- Failed on tt 1 mlx5_lag_destroy_definers() <- definers[tt=0] gets destroyed mlx5_lag_port_sel_create() mlx5_lag_create_definers() mlx5_lag_create_definer() <- Failed on tt 0 mlx5_lag_destroy_definers() <- definers[tt=0] gets double-destroyed Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 64k pages, 48-bit VAs, pgdp=0000000112ce2e00 [0000000000000008] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Modules linked in: iptable_raw bonding ip_gre ip6_gre gre ip6_tunnel tunnel6 geneve ip6_udp_tunnel udp_tunnel ipip tunnel4 ip_tunnel rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) mlx5_fwctl(OE) fwctl(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlxfw(OE) memtrack(OE) mlx_compat(OE) openvswitch nsh nf_conncount psample xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc netconsole overlay efi_pstore sch_fq_codel zram ip_tables crct10dif_ce qemu_fw_cfg fuse ipv6 crc_ccitt [last unloaded: mlx_compat(OE)] CPU: 3 UID: 0 PID: 217 Comm: kworker/u53:2 Tainted: G OE 6.11.0+ #2 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Workqueue: mlx5_lag mlx5_do_bond_work [mlx5_core] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mlx5_del_flow_rules+0x24/0x2c0 [mlx5_core] lr : mlx5_lag_destroy_definer+0x54/0x100 [mlx5_core] sp : ffff800085fafb00 x29: ffff800085fafb00 x28: ffff0000da0c8000 x27: 0000000000000000 x26: ffff0000da0c8000 x25: ffff0000da0c8000 x24: ffff0000da0c8000 x23: ffff0000c31f81a0 x22: 0400000000000000 x21: ffff0000da0c8000 x20: 0000000000000000 x19: 0000000000000001 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffff8b0c9350 x14: 0000000000000000 x13: ffff800081390d18 x12: ffff800081dc3cc0 x11: 0000000000000001 x10: 0000000000000b10 x9 : ffff80007ab7304c x8 : ffff0000d00711f0 x7 : 0000000000000004 x6 : 0000000000000190 x5 : ffff00027edb3010 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff0000d39b8000 x1 : ffff0000d39b8000 x0 : 0400000000000000 Call trace: mlx5_del_flow_rules+0x24/0x2c0 [mlx5_core] mlx5_lag_destroy_definer+0x54/0x100 [mlx5_core] mlx5_lag_destroy_definers+0xa0/0x108 [mlx5_core] mlx5_lag_port_sel_create+0x2d4/0x6f8 [mlx5_core] mlx5_activate_lag+0x60c/0x6f8 [mlx5_core] mlx5_do_bond_work+0x284/0x5c8 [mlx5_core] process_one_work+0x170/0x3e0 worker_thread+0x2d8/0x3e0 kthread+0x11c/0x128 ret_from_fork+0x10/0x20 Code: a9025bf5 aa0003f6 a90363f7 f90023f9 (f9400400) ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gtp: Destroy device along with udp socket's netns dismantle.gtp_newlink() links the device to a list in dev_net(dev) instead ofsrc_net, where a udp tunnel socket is created.Even when src_net is removed, the device stays alive on dev_net(dev).Then, removing src_net triggers the splat below. [0]In this example, gtp0 is created in ns2, and the udp socket is createdin ns1. ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1Let's link the device to the socket's netns instead.Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to removeall gtp devices in the netns.[0]:ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236) inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1558) udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18) gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423) gtp_create_sockets (drivers/net/gtp.c:1447) gtp_newlink (drivers/net/gtp.c:1507) rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlink_rcv_msg (net/core/rtnetlink.c:6922) netlink_rcv_skb (net/netlink/af_netlink.c:2542) netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347) netlink_sendmsg (net/netlink/af_netlink.c:1891) ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583) ___sys_sendmsg (net/socket.c:2639) __sys_sendmsg (net/socket.c:2669) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)WARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)Modules linked in:CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014Workqueue: netns cleanup_netRIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179)Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89RSP: 0018:ff11000009a07b60 EFLAGS: 00010286RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3cRBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395aeR10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? __warn (kernel/panic.c:748) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:285) ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467) cleanup_net (net/core/net_namespace.c:664 (discriminator 3)) process_one_work (kernel/workqueue.c:3229) worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb()This patch addresses a null-ptr-deref in qt2_process_read_urb() due toan incorrect bounds check in the following: if (newport > serial->num_ports) { dev_err(&port->dev, "%s - port change to invalid port: %i\n", __func__, newport); break; }The condition doesn't account for the valid range of the serial->portbuffer, which is from 0 to serial->num_ports - 1. When newport is equalto serial->num_ports, the assignment of "port" in thefollowing code is out-of-bounds and NULL: serial_priv->current_port = newport; port = serial->port[serial_priv->current_port];The fix checks if newport is greater than or equal to serial->num_portsindicating it is out-of-bounds.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: rtl8150: enable basic endpoint checkingSyzkaller reports [1] encountering a common issue of utilizing a wrongusb endpoint type during URB submitting stage. This, in turn, triggersa warning shown below.For now, enable simple endpoint checking (specifically, bulk andinterrupt eps, testing control one is not essential) to mitigatethe issue with a view to do other related cosmetic changes later,if they are necessary.[1] Syzkaller report:usb 1-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv>Modules linked in:CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617>Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8>RSP: 0018:ffffc9000441f740 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7cFS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fc04ef73d49...This change has not been tested on real hardware.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix a race for an ODP MR which leads to CQE with errorThis patch addresses a race condition for an ODP MR that can result in aCQE with an error on the UMR QP.During the __mlx5_ib_dereg_mr() flow, the following sequence of callsoccurs:mlx5_revoke_mr() mlx5r_umr_revoke_mr() mlx5r_umr_post_send_wait()At this point, the lkey is freed from the hardware's perspective.However, concurrently, mlx5_ib_invalidate_range() might be triggered byanother task attempting to invalidate a range for the same freed lkey.This task will: - Acquire the umem_odp->umem_mutex lock. - Call mlx5r_umr_update_xlt() on the UMR QP. - Since the lkey has already been freed, this can lead to a CQE error, causing the UMR QP to enter an error state [1].To resolve this race condition, the umem_odp->umem_mutex lock is now alsoacquired as part of the mlx5_revoke_mr() scope. Upon successful revoke,we set umem_odp->private which points to that MR to NULL, preventing anyfurther invalidation attempts on its lkey.[1] From dmesg: infiniband rocep8s0f0: dump_cqe:277:(pid 0): WC error: 6, Message: memory bind operation error cqe_dump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2 WARNING: CPU: 15 PID: 1506 at drivers/infiniband/hw/mlx5/umr.c:394 mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib] Modules linked in: ip6table_mangle ip6table_natip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core CPU: 15 UID: 0 PID: 1506 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1626 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib] [..] Call Trace: mlx5r_umr_update_xlt+0x23c/0x3e0 [mlx5_ib] mlx5_ib_invalidate_range+0x2e1/0x330 [mlx5_ib] __mmu_notifier_invalidate_range_start+0x1e1/0x240 zap_page_range_single+0xf1/0x1a0 madvise_vma_behavior+0x677/0x6e0 do_madvise+0x1a2/0x4b0 __x64_sys_madvise+0x25/0x30 do_syscall_64+0x6b/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing/osnoise: Fix resetting of tracepointsIf a timerlat tracer is started with the osnoise option OSNOISE_WORKLOADdisabled, but then that option is enabled and timerlat is removed, thetracepoints that were enabled on timerlat registration do not getdisabled. If the option is disabled again and timelat is started, then ittriggers a warning in the tracepoint code due to registering thetracepoint again without ever disabling it.Do not use the same user space defined options to know to disable thetracepoints when timerlat is removed. Instead, set a global flag when itis enabled and use that flag to know to disable the events. ~# echo NO_OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options ~# echo timerlat > /sys/kernel/tracing/current_tracer ~# echo OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options ~# echo nop > /sys/kernel/tracing/current_tracer ~# echo NO_OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options ~# echo timerlat > /sys/kernel/tracing/current_tracerTriggers: ------------[ cut here ]------------ WARNING: CPU: 6 PID: 1337 at kernel/tracepoint.c:294 tracepoint_add_func+0x3b6/0x3f0 Modules linked in: CPU: 6 UID: 0 PID: 1337 Comm: rtla Not tainted 6.13.0-rc4-test-00018-ga867c441128e-dirty #73 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tracepoint_add_func+0x3b6/0x3f0 Code: 48 8b 53 28 48 8b 73 20 4c 89 04 24 e8 23 59 11 00 4c 8b 04 24 e9 36 fe ff ff 0f 0b b8 ea ff ff ff 45 84 e4 0f 84 68 fe ff ff <0f> 0b e9 61 fe ff ff 48 8b 7b 18 48 85 ff 0f 84 4f ff ff ff 49 8b RSP: 0018:ffffb9b003a87ca0 EFLAGS: 00010202 RAX: 00000000ffffffef RBX: ffffffff92f30860 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9bf59e91ccd0 RDI: ffffffff913b6410 RBP: 000000000000000a R08: 00000000000005c7 R09: 0000000000000002 R10: ffffb9b003a87ce0 R11: 0000000000000002 R12: 0000000000000001 R13: ffffb9b003a87ce0 R14: ffffffffffffffef R15: 0000000000000008 FS: 00007fce81209240(0000) GS:ffff9bf6fdd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055e99b728000 CR3: 00000001277c0002 CR4: 0000000000172ef0 Call Trace: ? __warn.cold+0xb7/0x14d ? tracepoint_add_func+0x3b6/0x3f0 ? report_bug+0xea/0x170 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? __pfx_trace_sched_migrate_callback+0x10/0x10 ? tracepoint_add_func+0x3b6/0x3f0 ? __pfx_trace_sched_migrate_callback+0x10/0x10 ? __pfx_trace_sched_migrate_callback+0x10/0x10 tracepoint_probe_register+0x78/0xb0 ? __pfx_trace_sched_migrate_callback+0x10/0x10 osnoise_workload_start+0x2b5/0x370 timerlat_tracer_init+0x76/0x1b0 tracing_set_tracer+0x244/0x400 tracing_set_trace_write+0xa0/0xe0 vfs_write+0xfc/0x570 ? do_sys_openat2+0x9c/0xe0 ksys_write+0x72/0xf0 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:misc: fastrpc: Fix copy buffer page sizeFor non-registered buffer, fastrpc driver copies the buffer andpass it to the remote subsystem. There is a problem with currentimplementation of page size calculation which is not consideringthe offset in the calculation. This might lead to passing ofimproper and out-of-bounds page size which could result inmemory issue. Calculate page start and page end using the offsetadjusted address instead of absolute address.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFC: nci: Add bounds checking in nci_hci_create_pipe()The "pipe" variable is a u8 which comes from the network. If it's morethan 127, then it results in memory corruption in the caller,nci_hci_connect_gate().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix possible int overflows in nilfs_fiemap()Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its resultby being prepared to go through potentially maxblocks == INT_MAX blocks,the value in n may experience an overflow caused by left shift of blkbits.While it is extremely unlikely to occur, play it safe and cast right handexpression to wider type to mitigate the issue.Found by Linux Verification Center (linuxtesting.org) with static analysistool SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix memory leak in ceph_mds_auth_match()We now free the temporary target path substring allocation on everypossible branch, instead of omitting the default branch. In somecases, a memory leak occured, which could rapidly crash the system(depending on how many file accesses were attempted).This was detected in production because it caused a continuous memorygrowth, eventually triggering kernel OOM and completely hard-lockingthe kernel.Relevant kmemleak stacktrace: unreferenced object 0xffff888131e69900 (size 128): comm "git", pid 66104, jiffies 4295435999 hex dump (first 32 bytes): 76 6f 6c 75 6d 65 73 2f 63 6f 6e 74 61 69 6e 65 volumes/containe 72 73 2f 67 69 74 65 61 2f 67 69 74 65 61 2f 67 rs/gitea/gitea/g backtrace (crc 2f3bb450): [] __kmalloc_noprof+0x359/0x510 [] ceph_mds_check_access+0x5bf/0x14e0 [ceph] [] ceph_open+0x312/0xd80 [ceph] [] do_dentry_open+0x456/0x1120 [] vfs_open+0x79/0x360 [] path_openat+0x1de5/0x4390 [] do_filp_open+0x19c/0x3c0 [] do_sys_openat2+0x141/0x180 [] __x64_sys_open+0xe5/0x1a0 [] do_syscall_64+0xb7/0x210 [] entry_SYSCALL_64_after_hwframe+0x77/0x7fIt can be triggered by mouting a subdirectory of a CephFS filesystem,and then trying to access files on this subdirectory with an auth tokenusing a path-scoped capability: $ ceph auth get client.services [client.services] key = REDACTED caps mds = "allow rw fsname=cephfs path=/volumes/" caps mon = "allow r fsname=cephfs" caps osd = "allow rw tag cephfs data=cephfs" $ cat /proc/self/mounts services@[REDACTED].cephfs=/volumes/containers /ceph/containers ceph rw,noatime,name=services,secret=,ms_mode=prefer-crc,mount_timeout=300,acl,mon_addr=[REDACTED]:3300,recover_session=clean 0 0 $ seq 1 1000000 | xargs -P32 --replace={} touch /ceph/containers/file-{} && \ seq 1 1000000 | xargs -P32 --replace={} cat /ceph/containers/file-{}[ idryomov: combine if statements, rename rc to path_matched and make it a bool, formatting ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: ipheth: fix DPE OoB readFix an out-of-bounds DPE read, limit the number of processed DPEs tothe amount that fits into the fixed-size NDP16 header.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: ipheth: use static NDP16 location in URBOriginal code allowed for the start of NDP16 to be anywhere within theURB based on the `wNdpIndex` value in NTH16. Only the start position ofNDP16 was checked, so it was possible for even the fixed-length partof NDP16 to extend past the end of URB, leading to an out-of-boundsread.On iOS devices, the NDP16 header always directly follows NTH16. Rely onand check for this specific format.This, along with NCM-specific minimal URB length check that alreadyexists, will ensure that the fixed-length part of NDP16 plus a setamount of DPEs fit within the URB.Note that this commit alone does not fully address the OoB read.The limit on the amount of DPEs needs to be enforced separately.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: ipheth: fix possible overflow in DPE length checkOriginally, it was possible for the DPE length check to overflow ifwDatagramIndex + wDatagramLength > U16_MAX. This could lead to an OoBread.Move the wDatagramIndex term to the other side of the inequality.An existing condition ensures that wDatagramIndex < urb->actual_length.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()On removal of the device or unloading of the kernel module a potential NULLpointer dereference occurs.The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if()Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated toBRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.After brcmf_remove_interface() call the brcmf_proto_detach() function iscalled providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize()Since brcmf_get_ip() can and actually will return NULL in this case thecall to brcmf_txfinalize() will result in a NULL pointer dereference insidebrcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors.This will only happen if a flowring still has an skb.Although the NULL pointer dereference has only been seen when trying toupdate the tx statistic, all other uses of the ifp pointer have beenguarded as well with an early return if ifp is NULL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: Fix class @block_class's subsystem refcount leakageblkcg_fill_root_iostats() iterates over @block_class's devices byclass_dev_iter_(init|next)(), but does not end iterating withclass_dev_iter_exit(), so causes the class's subsystem refcount leakage.Fix by ending the iterating with class_dev_iter_exit().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/ast: astdp: Fix timeout for enabling video signalThe ASTDP transmitter sometimes takes up to 1 second for enabling thevideo signal, while the timeout is only 200 msec. This results in akernel error message. Increase the timeout to 1 second. An exampleof the error message is shown below.[ 697.084433] ------------[ cut here ]------------[ 697.091115] ast 0000:02:00.0: [drm] drm_WARN_ON(!__ast_dp_wait_enable(ast, enabled))[ 697.091233] WARNING: CPU: 1 PID: 160 at drivers/gpu/drm/ast/ast_dp.c:232 ast_dp_set_enable+0x123/0x140 [ast][...][ 697.272469] RIP: 0010:ast_dp_set_enable+0x123/0x140 [ast][...][ 697.415283] Call Trace:[ 697.420727] [ 697.425908] ? show_trace_log_lvl+0x196/0x2c0[ 697.433304] ? show_trace_log_lvl+0x196/0x2c0[ 697.440693] ? drm_atomic_helper_commit_modeset_enables+0x30a/0x470[ 697.450115] ? ast_dp_set_enable+0x123/0x140 [ast][ 697.458059] ? __warn.cold+0xaf/0xca[ 697.464713] ? ast_dp_set_enable+0x123/0x140 [ast][ 697.472633] ? report_bug+0x134/0x1d0[ 697.479544] ? handle_bug+0x58/0x90[ 697.486127] ? exc_invalid_op+0x13/0x40[ 697.492975] ? asm_exc_invalid_op+0x16/0x20[ 697.500224] ? preempt_count_sub+0x14/0xc0[ 697.507473] ? ast_dp_set_enable+0x123/0x140 [ast][ 697.515377] ? ast_dp_set_enable+0x123/0x140 [ast][ 697.523227] drm_atomic_helper_commit_modeset_enables+0x30a/0x470[ 697.532388] drm_atomic_helper_commit_tail+0x58/0x90[ 697.540400] ast_mode_config_helper_atomic_commit_tail+0x30/0x40 [ast][ 697.550009] commit_tail+0xfe/0x1d0[ 697.556547] drm_atomic_helper_commit+0x198/0x1c0This is a cosmetical problem. Enabling the video signal still workseven with the error message. The problem has always been present, butonly recent versions of the ast driver warn about missing the timeout.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Check the return value of of_property_read_string_index()Somewhen between 6.10 and 6.11 the driver started to crash on myMacBookPro14,3. The property doesn't exist and 'tmp' remainsuninitialized, so we pass a random pointer to devm_kstrdup().The crash I am getting looks like this:BUG: unable to handle page fault for address: 00007f033c669379PF: supervisor read access in kernel modePF: error_code(0x0001) - permissions violationPGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025Oops: Oops: 0001 [#1] SMP PTICPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024RIP: 0010:strlen+0x4/0x30Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 ccRSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916aR10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x149/0x4c0 ? raw_spin_rq_lock_nested+0xe/0x20 ? sched_balance_newidle+0x22b/0x3c0 ? update_load_avg+0x78/0x770 ? exc_page_fault+0x6f/0x150 ? asm_exc_page_fault+0x26/0x30 ? __pfx_pci_conf1_write+0x10/0x10 ? strlen+0x4/0x30 devm_kstrdup+0x25/0x70 brcmf_of_probe+0x273/0x350 [brcmfmac]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix assertion failure when splitting ordered extent after transaction abortIf while we are doing a direct IO write a transaction abort happens, wemark all existing ordered extents with the BTRFS_ORDERED_IOERR flag (doneat btrfs_destroy_ordered_extents()), and then after that if we enterbtrfs_split_ordered_extent() and the ordered extent has bytes left(meaning we have a bio that doesn't cover the whole ordered extent, seedetails at btrfs_extract_ordered_extent()), we will fail on the followingassertion at btrfs_split_ordered_extent(): ASSERT(!(flags & ~BTRFS_ORDERED_TYPE_FLAGS));because the BTRFS_ORDERED_IOERR flag is set and the definition ofBTRFS_ORDERED_TYPE_FLAGS is just the union of all flags that identify thetype of write (regular, nocow, prealloc, compressed, direct IO, encoded).Fix this by returning an error from btrfs_extract_ordered_extent() if wefind the BTRFS_ORDERED_IOERR flag in the ordered extent. The error willbe the error that resulted in the transaction abort or -EIO if notransaction abort happened.This was recently reported by syzbot with the following trace: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 CPU: 0 UID: 0 PID: 5321 Comm: syz.0.0 Not tainted 6.13.0-rc5-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 fail_dump lib/fault-inject.c:53 [inline] should_fail_ex+0x3b0/0x4e0 lib/fault-inject.c:154 should_failslab+0xac/0x100 mm/failslab.c:46 slab_pre_alloc_hook mm/slub.c:4072 [inline] slab_alloc_node mm/slub.c:4148 [inline] __do_kmalloc_node mm/slub.c:4297 [inline] __kmalloc_noprof+0xdd/0x4c0 mm/slub.c:4310 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] btrfs_chunk_alloc_add_chunk_item+0x244/0x1100 fs/btrfs/volumes.c:5742 reserve_chunk_space+0x1ca/0x2c0 fs/btrfs/block-group.c:4292 check_system_chunk fs/btrfs/block-group.c:4319 [inline] do_chunk_alloc fs/btrfs/block-group.c:3891 [inline] btrfs_chunk_alloc+0x77b/0xf80 fs/btrfs/block-group.c:4187 find_free_extent_update_loop fs/btrfs/extent-tree.c:4166 [inline] find_free_extent+0x42d1/0x5810 fs/btrfs/extent-tree.c:4579 btrfs_reserve_extent+0x422/0x810 fs/btrfs/extent-tree.c:4672 btrfs_new_extent_direct fs/btrfs/direct-io.c:186 [inline] btrfs_get_blocks_direct_write+0x706/0xfa0 fs/btrfs/direct-io.c:321 btrfs_dio_iomap_begin+0xbb7/0x1180 fs/btrfs/direct-io.c:525 iomap_iter+0x697/0xf60 fs/iomap/iter.c:90 __iomap_dio_rw+0xeb9/0x25b0 fs/iomap/direct-io.c:702 btrfs_dio_write fs/btrfs/direct-io.c:775 [inline] btrfs_direct_write+0x610/0xa30 fs/btrfs/direct-io.c:880 btrfs_do_write_iter+0x2a0/0x760 fs/btrfs/file.c:1397 do_iter_readv_writev+0x600/0x880 vfs_writev+0x376/0xba0 fs/read_write.c:1050 do_pwritev fs/read_write.c:1146 [inline] __do_sys_pwritev2 fs/read_write.c:1204 [inline] __se_sys_pwritev2+0x196/0x2b0 fs/read_write.c:1195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f1281f85d29 RSP: 002b:00007f12819fe038 EFLAGS: 00000246 ORIG_RAX: 0000000000000148 RAX: ffffffffffffffda RBX: 00007f1282176080 RCX: 00007f1281f85d29 RDX: 0000000000000001 RSI: 0000000020000240 RDI: 0000000000000005 RBP: 00007f12819fe090 R08: 0000000000000000 R09: 0000000000000003 R10: 0000000000007000 R11: 0000000000000246 R12: 0000000000000002 R13: 0000000000000000 R14: 00007f1282176080 R15: 00007ffcb9e23328 BTRFS error (device loop0 state A): Transaction aborted (error -12) BTRFS: error (device loop0 state A---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: add RCU protection to mld_newpack()mld_newpack() can be called without RTNL or RCU being held.Note that we no longer can use sock_alloc_send_skb() becauseipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.Instead use alloc_skb() and charge the net->ipv6.igmp_sksocket under RCU protection.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: extend RCU protection in igmp6_send()igmp6_send() can be called without RTNL or RCU being held.Extend RCU protection so that we can safely fetch the net pointerand avoid a potential UAF.Note that we no longer can use sock_alloc_send_skb() becauseipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.Instead use alloc_skb() and charge the net->ipv6.igmp_sksocket under RCU protection.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:openvswitch: use RCU protection in ovs_vport_cmd_fill_info()ovs_vport_cmd_fill_info() can be called without RTNL or RCU.Use RCU protection and dev_net_rcu() to avoid potential UAF.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arp: use RCU protection in arp_xmit()arp_xmit() can be called without RTNL or RCU protection.Use RCU protection to avoid potential UAF.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:neighbour: use RCU protection in __neigh_notify()__neigh_notify() can be called without RTNL or RCU protection.Use RCU protection to avoid potential UAF.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic contextThe following bug report happened with a PREEMPT_RT kernel: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 get_random_u32+0x4f/0x110 clocksource_verify_choose_cpus+0xab/0x1a0 clocksource_verify_percpu.part.0+0x6b/0x330 clocksource_watchdog_kthread+0x193/0x1a0It is due to the fact that clocksource_verify_choose_cpus() is invoked withpreemption disabled. This function invokes get_random_u32() to obtainrandom numbers for choosing CPUs. The batched_entropy_32 local lock and/orthe base_crng.lock spinlock in driver/char/random.c will be acquired duringthe call. In PREEMPT_RT kernel, they are both sleeping locks and so cannotbe acquired in atomic context.Fix this problem by using migrate_disable() to allow smp_processor_id() tobe reliably used without introducing atomic context. preempt_disable() isthen called after clocksource_verify_choose_cpus() but before theclocksource measurement is being run to avoid introducing unexpectedlatency.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnelsSome lwtunnels have a dst cache for post-transformation dst.If the packet destination did not change we may end up recordinga reference to the lwtunnel in its own cache, and the lwtunnelstate will never be freed.Discovered by the ioam6.sh test, kmemleak was recently fixedto catch per-cpu memory leaks. I'm not sure if rpl and seg6can actually hit this, but in principle I don't see why not.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: vmclock: Add .owner to vmclock_miscdev_fopsWithout the .owner field, the module can be unloaded while /dev/vmclock0is open, leading to an oops.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu: Fix potential memory leak in iopf_queue_remove_device()The iopf_queue_remove_device() helper removes a device from the per-iommuiopf queue when PRI is disabled on the device. It responds to alloutstanding iopf's with an IOMMU_PAGE_RESP_INVALID code and detaches thedevice from the queue.However, it fails to release the group structure that represents a groupof iopf's awaiting for a response after responding to the hardware. Thiscan cause a memory leak if iopf_queue_remove_device() is called withpending iopf's.Fix it by calling iopf_free_group() after the iopf group is responded.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched_ext: Fix incorrect autogroup migration detectionscx_move_task() is called from sched_move_task() and tells the BPF schedulerthat cgroup migration is being committed. sched_move_task() is used by bothcgroup and autogroup migrations and scx_move_task() tried to filter outautogroup migrations by testing the destination cgroup and PF_EXITING butthis is not enough. In fact, without explicitly tagging the thread which isdoing the cgroup migration, there is no good way to tell apartscx_move_task() invocations for racing migration to the root cgroup and anautogroup migration.This led to scx_move_task() incorrectly ignoring a migration from non-rootcgroup to an autogroup of the root cgroup triggering the following warning: WARNING: CPU: 7 PID: 1 at kernel/sched/ext.c:3725 scx_cgroup_can_attach+0x196/0x340 ... Call Trace: cgroup_migrate_execute+0x5b1/0x700 cgroup_attach_task+0x296/0x400 __cgroup_procs_write+0x128/0x140 cgroup_procs_write+0x17/0x30 kernfs_fop_write_iter+0x141/0x1f0 vfs_write+0x31d/0x4a0 __x64_sys_write+0x72/0xf0 do_syscall_64+0x82/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7eFix it by adding an argument to sched_move_task() that indicates whether themoving is for a cgroup or autogroup migration. After the change,scx_move_task() is called only for cgroup migrations and renamed toscx_cgroup_move_task().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: etas_es58x: fix potential NULL pointer dereference on udev->serialThe driver assumed that es58x_dev->udev->serial could never be NULL.While this is true on commercially available devices, an attackercould spoof the device identity providing a NULL USB serial number.That would trigger a NULL pointer dereference.Add a check on es58x_dev->udev->serial before accessing it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: rockchip: rkcanfd_handle_rx_fifo_overflow_int(): bail out if skb cannot be allocatedFix NULL pointer check in rkcanfd_handle_rx_fifo_overflow_int() tobail out if skb cannot be allocated.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: ctucanfd: handle skb allocation failureIf skb allocation fails, the pointer to struct can_frame is NULL. Thisis actually handled everywhere inside ctucan_err_interrupt() except forthe only place.Add the missed NULL check.Found by Linux Verification Center (linuxtesting.org) with SVACE staticanalysis tool.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: hub: Ignore non-compliant devices with too many configs or interfacesRobert Morris created a test program which can causeusb_hub_to_struct_hub() to dereference a NULL or inappropriatepointer:Oops: general protection fault, probably for non-canonical address0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTICPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110...Call Trace: ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0The cause of this error is that the device has two interfaces, and thehub driver binds to interface 1 instead of interface 0, which is whereusb_hub_to_struct_hub() looks.We can prevent the problem from occurring by refusing to accept hubdevices that violate the USB spec by having more than oneconfiguration or interface.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Validate the persistent meta data subbuf arrayThe meta data for a mapped ring buffer contains an array of indexes of allthe subbuffers. The first entry is the reader page, and the rest of theentries lay out the order of the subbuffers in how the ring buffer linklist is to be created.The validator currently makes sure that all the entries are within therange of 0 and nr_subbufs. But it does not check if there are anyduplicates.While working on the ring buffer, I corrupted this array, where I addedduplicates. The validator did not catch it and created the ring bufferlink list on top of it. Luckily, the corruption was only that the readerpage was also in the writer path and only presented corrupted data but didnot crash the kernel. But if there were duplicates in the writer side,then it could corrupt the ring buffer link list and cause a crash.Create a bitmask array with the size of the number of subbuffers. Thenclear it. When walking through the subbuf array checking to see if theentries are within the range, test if its bit is already set in thesubbuf_mask. If it is, then there is duplicates and fail the validation.If not, set the corresponding bit and continue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Do not allow mmap() of persistent ring bufferWhen trying to mmap a trace instance buffer that is attached toreserve_mem, it would crash: BUG: unable to handle page fault for address: ffffe97bd00025c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 2862f3067 P4D 2862f3067 PUD 0 Oops: Oops: 0000 [#1] PREEMPT_RT SMP PTI CPU: 4 UID: 0 PID: 981 Comm: mmap-rb Not tainted 6.14.0-rc2-test-00003-g7f1a5e3fbf9e-dirty #233 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:validate_page_before_insert+0x5/0xb0 Code: e2 01 89 d0 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 <48> 8b 46 08 a8 01 75 67 66 90 48 89 f0 8b 50 34 85 d2 74 76 48 89 RSP: 0018:ffffb148c2f3f968 EFLAGS: 00010246 RAX: ffff9fa5d3322000 RBX: ffff9fa5ccff9c08 RCX: 00000000b879ed29 RDX: ffffe97bd00025c0 RSI: ffffe97bd00025c0 RDI: ffff9fa5ccff9c08 RBP: ffffb148c2f3f9f0 R08: 0000000000000004 R09: 0000000000000004 R10: 0000000000000000 R11: 0000000000000200 R12: 0000000000000000 R13: 00007f16a18d5000 R14: ffff9fa5c48db6a8 R15: 0000000000000000 FS: 00007f16a1b54740(0000) GS:ffff9fa73df00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffe97bd00025c8 CR3: 00000001048c6006 CR4: 0000000000172ef0 Call Trace: ? __die_body.cold+0x19/0x1f ? __die+0x2e/0x40 ? page_fault_oops+0x157/0x2b0 ? search_module_extables+0x53/0x80 ? validate_page_before_insert+0x5/0xb0 ? kernelmode_fixup_or_oops.isra.0+0x5f/0x70 ? __bad_area_nosemaphore+0x16e/0x1b0 ? bad_area_nosemaphore+0x16/0x20 ? do_kern_addr_fault+0x77/0x90 ? exc_page_fault+0x22b/0x230 ? asm_exc_page_fault+0x2b/0x30 ? validate_page_before_insert+0x5/0xb0 ? vm_insert_pages+0x151/0x400 __rb_map_vma+0x21f/0x3f0 ring_buffer_map+0x21b/0x2f0 tracing_buffers_mmap+0x70/0xd0 __mmap_region+0x6f0/0xbd0 mmap_region+0x7f/0x130 do_mmap+0x475/0x610 vm_mmap_pgoff+0xf2/0x1d0 ksys_mmap_pgoff+0x166/0x200 __x64_sys_mmap+0x37/0x50 x64_sys_call+0x1670/0x1d70 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe reason was that the code that maps the ring buffer pages to user spacehas: page = virt_to_page((void *)cpu_buffer->subbuf_ids[s]);And uses that in: vm_insert_pages(vma, vma->vm_start, pages, &nr_pages);But virt_to_page() does not work with vmap()'d memory which is what thepersistent ring buffer has. It is rather trivial to allow this, but fornow just disable mmap() of instances that have their ring buffer from thereserve_mem option.If an mmap() is performed on a persistent buffer it will return -ENODEVjust like it would if the .mmap field wasn't defined in thefile_operations structure.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernelAdvertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if andonly if the local API is emulated/virtualized by KVM, and explicitly rejectsaid hypercalls if the local APIC is emulated in userspace, i.e. don't relyon userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference ifHyper-V enlightenments are exposed to the guest without an in-kernel localAPIC: dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1Note, checking the sending vCPU is sufficient, as the per-VM irqchip_modecan't be modified after vCPUs are created, i.e. if one vCPU has anin-kernel local APIC, then all vCPUs have an in-kernel local APIC.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: fix panic during interface removalReference counting is used to ensure thatbatadv_hardif_neigh_node and batadv_hard_ifaceare not freed before/duringbatadv_v_elp_throughput_metric_update work isfinished.But there isn't a guarantee that the hard if willremain associated with a soft interface up untilthe work is finished.This fixes a crash triggered by reboot that lookslike this:Call trace: batadv_v_mesh_free+0xd0/0x4dc [batman_adv] batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x178/0x398 worker_thread+0x2e8/0x4d0 kthread+0xd8/0xdc ret_from_fork+0x10/0x20(the batadv_v_mesh_free call is misleading,and does not actually happen)I was able to make the issue happen more reliablyby changing hardif_neigh->bat_v.metric_work workto be delayed work. This allowed me to track downand confirm the fix.[sven@narfation.org: prevent entering batadv_v_elp_get_throughput without soft_iface]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpiolib: Fix crash on error in gpiochip_get_ngpios()The gpiochip_get_ngpios() uses chip_*() macros to print messages.However these macros rely on gpiodev to be initialised and set,which is not the case when called via bgpio_init(). In such a casethe printing messages will crash on NULL pointer dereference.Replace chip_*() macros by the respective dev_*() ones to avoidsuch crash.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: bail out when failed to load fw in psp_init_cap_microcode()In function psp_init_cap_microcode(), it should bail out when failed toload firmware, otherwise it may cause invalid memory access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:workqueue: Put the pwq after detaching the rescuer from the poolThe commit 68f83057b913("workqueue: Reap workers via kthread_stop() andremove detach_completion") adds code to reap the normal workers butmistakenly does not handle the rescuer and also removes the code waitingfor the rescuer in put_unbound_pool(), which caused a use-after-free bugreported by Cheung Wall.To avoid the use-after-free bug, the pool's reference must be held untilthe detachment is complete. Therefore, move the code that puts the pwqafter detaching the rescuer from the pool.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:team: better TEAM_OPTION_TYPE_STRING validationsyzbot reported following splat [1]Make sure user-provided data contains one nul byte.[1] BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 string_nocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 __request_module+0x252/0x9f0 kernel/module/kmod.c:149 team_mode_get drivers/net/team/team_core.c:480 [inline] team_change_mode drivers/net/team/team_core.c:607 [inline] team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401 team_option_set drivers/net/team/team_core.c:375 [inline] team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:733 ____sys_sendmsg+0x877/0xb60 net/socket.c:2573 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627 __sys_sendmsg net/socket.c:2659 [inline] __do_sys_sendmsg net/socket.c:2664 [inline] __se_sys_sendmsg net/socket.c:2662 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: ti: am65-cpsw: fix memleak in certain XDP casesIf the XDP program doesn't result in XDP_PASS then we leak thememory allocated by am65_cpsw_build_skb().It is pointless to allocate SKB memory before running the XDPprogram as we would be wasting CPU cycles for cases other than XDP_PASS.Move the SKB allocation after evaluating the XDP program result.This fixes the memleak. A performance boost is seen for XDP_DROP test.XDP_DROP test:Before: 460256 rx/s 0 err/sAfter: 784130 rx/s 0 err/s
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: check vxlan_vnigroup_init() return valuevxlan_init() must check vxlan_vnigroup_init() successotherwise a crash happens later, spotted by syzbot.Oops: general protection fault, probably for non-canonical address 0xdffffc000000002c: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000160-0x0000000000000167]CPU: 0 UID: 0 PID: 7313 Comm: syz-executor147 Not tainted 6.14.0-rc1-syzkaller-00276-g69b54314c975 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:vxlan_vnigroup_uninit+0x89/0x500 drivers/net/vxlan/vxlan_vnifilter.c:912Code: 00 48 8b 44 24 08 4c 8b b0 98 41 00 00 49 8d 86 60 01 00 00 48 89 c2 48 89 44 24 10 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4d 04 00 00 49 8b 86 60 01 00 00 48 ba 00 00 00RSP: 0018:ffffc9000cc1eea8 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffffff8672effbRDX: 000000000000002c RSI: ffffffff8672ecb9 RDI: ffff8880461b4f18RBP: ffff8880461b4ef4 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000020000R13: ffff8880461b0d80 R14: 0000000000000000 R15: dffffc0000000000FS: 00007fecfa95d6c0(0000) GS:ffff88806a600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fecfa95cfb8 CR3: 000000004472c000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: vxlan_uninit+0x1ab/0x200 drivers/net/vxlan/vxlan_core.c:2942 unregister_netdevice_many_notify+0x12d6/0x1f30 net/core/dev.c:11824 unregister_netdevice_many net/core/dev.c:11866 [inline] unregister_netdevice_queue+0x307/0x3f0 net/core/dev.c:11736 register_netdevice+0x1829/0x1eb0 net/core/dev.c:10901 __vxlan_dev_create+0x7c6/0xa30 drivers/net/vxlan/vxlan_core.c:3981 vxlan_newlink+0xd1/0x130 drivers/net/vxlan/vxlan_core.c:4407 rtnl_newlink_create net/core/rtnetlink.c:3795 [inline] __rtnl_newlink net/core/rtnetlink.c:3906 [inline]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ax25: Fix refcount leak caused by setting SO_BINDTODEVICE sockoptIf an AX25 device is bound to a socket by setting the SO_BINDTODEVICEsocket option, a refcount leak will occur in ax25_release().Commit 9fd75b66b8f6 ("ax25: Fix refcount leaks caused by ax25_cb_del()")added decrement of device refcounts in ax25_release(). In order for thatto work correctly the refcounts must already be incremented when thedevice is bound to the socket. An AX25 device can be bound to a socketby either calling ax25_bind() or setting SO_BINDTODEVICE socket option.In both cases the refcounts should be incremented, but in fact it is doneonly in ax25_bind().This bug leads to the following issue reported by Syzkaller:================================================================refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 1 PID: 5932 at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31Modules linked in:CPU: 1 UID: 0 PID: 5932 Comm: syz-executor424 Not tainted 6.13.0-rc4-syzkaller-00110-g4099a71718b0 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31Call Trace: __refcount_dec include/linux/refcount.h:336 [inline] refcount_dec include/linux/refcount.h:351 [inline] ref_tracker_free+0x710/0x820 lib/ref_tracker.c:236 netdev_tracker_free include/linux/netdevice.h:4156 [inline] netdev_put include/linux/netdevice.h:4173 [inline] netdev_put include/linux/netdevice.h:4169 [inline] ax25_release+0x33f/0xa10 net/ax25/af_ax25.c:1069 __sock_release+0xb0/0x270 net/socket.c:640 sock_close+0x1c/0x30 net/socket.c:1408 ... do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... ================================================================Fix the implementation of ax25_setsockopt() by adding increment ofrefcounts for the new device bound, and decrement of refcounts forthe old unbound device.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: sn-f-ospi: Fix division by zeroWhen there is no dummy cycle in the spi-nor commands, both dummy bus cyclebytes and width are zero. Because of the cpu's warning when divided byzero, the warning should be avoided. Return just zero to avoid suchcalculations.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: hid-thrustmaster: fix stack-out-of-bounds read in usb_check_int_endpoints()Syzbot[1] has detected a stack-out-of-bounds read of the ep_addr array fromhid-thrustmaster driver. This array is passed to usb_check_int_endpointsfunction from usb.c core driver, which executes a for loop that iteratesover the elements of the passed array. Not finding a null element at the end ofthe array, it tries to read the next, non-existent element, crashing the kernel.To fix this, a 0 element was added at the end of the array to break the forloop.[1] https://syzkaller.appspot.com/bug?extid=9c9179ac46169c56c1ad
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: fix hang in nfsd4_shutdown_callbackIf nfs4_client is in courtesy state then there is no point to sendthe callback. This causes nfsd4_shutdown_callback to hang sincecl_cb_inflight is not 0. This hang lasts about 15 minutes until TCPnotifies NFSD that the connection was dropped.This patch modifies nfsd4_run_cb_work to skip the RPC call ifnfs4_client is in courtesy state.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: clear acl_access/acl_default after releasing themIf getting acl_default fails, acl_access and acl_default will be releasedsimultaneously. However, acl_access will still retain a pointer pointingto the released posix_acl, which will trigger a WARNING innfs3svc_release_getacl like this:------------[ cut here ]------------refcount_t: underflow; use-after-free.WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28refcount_warn_saturate+0xb5/0x170Modules linked in:CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted6.12.0-rc6-00079-g04ae226af01f-dirty #8Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014RIP: 0010:refcount_warn_saturate+0xb5/0x170Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b ebcd 0f b6 1d 8a3RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fdeRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0FS: 0000000000000000(0000) GS:ffff88871ed00000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ? __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ? __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Kernel panic - not syncing: kernel: panic_on_warn set ...Clear acl_access/acl_default after posix_acl_release is called to preventUAF from being triggered.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: corsair-void: Add missing delayed work cancel for headset statusThe cancel_delayed_work_sync() call was missed, causing a use-after-freein corsair_void_remove().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:timers/migration: Fix off-by-one root mis-connectionBefore attaching a new root to the old root, the children counter of thenew root is checked to verify that only the upcoming CPU's top group havebeen connected to it. However since the recently added commit b729cc1ec21a("timers/migration: Fix another race between hotplug and idle entry/exit")this check is not valid anymore because the old root is pre-accountedas a child to the new root. Therefore after connecting the upcomingCPU's top group to the new root, the children count to be expected mustbe 2 and not 1 anymore.This omission results in the old root to not be connected to the newroot. Then eventually the system may run with more than one top level,which defeats the purpose of a single idle migrator.Also the old root is pre-accounted but not connected upon the new rootcreation. But it can be connected to the new root later on. Thereforethe old root may be accounted twice to the new root. The propagation ofsuch overcommit can end up creating a double final top-level root with agroupmask incorrectly initialized. Although harmless given that the finaltop level roots will never have a parent to walk up to, this oddityopportunistically reported the core issue: WARNING: CPU: 8 PID: 0 at kernel/time/timer_migration.c:543 tmigr_requires_handle_remote CPU: 8 UID: 0 PID: 0 Comm: swapper/8 RIP: 0010:tmigr_requires_handle_remote Call Trace: ? tmigr_requires_handle_remote ? hrtimer_run_queues update_process_times tick_periodic tick_handle_periodic __sysvec_apic_timer_interrupt sysvec_apic_timer_interrupt Fix the problem by taking the old root into account in the children countof the new root so the connection is not omitted.Also warn when more than one top level group exists to better detectsimilar issues in the future.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: Ensure info->enable callback is always setThe ioctl and sysfs handlers unconditionally call the ->enable callback.Not all drivers implement that callback, leading to NULL dereferences.Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.Instead use a dummy callback if no better was specified by the driver.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/compaction: fix UBSAN shift-out-of-bounds warningsyzkaller reported a UBSAN shift-out-of-bounds warning of (1UL << order)in isolate_freepages_block(). The bogus compound_order can be any valuebecause it is union with flags. Add back the MAX_PAGE_ORDER check to fixthe warning.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYINGhrtimers are migrated away from the dying CPU to any online target atthe CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timershandling tasks involved in the CPU hotplug forward progress.However wakeups can still be performed by the outgoing CPU afterCPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers beingarmed. Depending on several considerations (crystal ball power managementbased election, earliest timer already enqueued, timer migration enabled ornot), the target may eventually be the current CPU even if offline. If thathappens, the timer is eventually ignored.The most notable example is RCU which had to deal with each and every ofthose wake-ups by deferring them to an online CPU, along with relatedworkarounds:_ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying)_ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU)_ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)The problem isn't confined to RCU though as the stop machine kthread(which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the endof its work through cpu_stop_signal_done() and performs a wake up thateventually arms the deadline server timer: WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0 CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted Stopper: multi_cpu_stop+0x0/0x120 <- stop_machine_cpuslocked+0x66/0xc0 RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0 Call Trace: start_dl_timer enqueue_dl_entity dl_server_start enqueue_task_fair enqueue_task ttwu_do_activate try_to_wake_up complete cpu_stopper_threadInstead of providing yet another bandaid to work around the situation, fixit in the hrtimers infrastructure instead: always migrate away a timer toan online target whenever it is enqueued from an offline CPU.This will also allow to revert all the above RCU disgraceful hacks.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Revert "drm/amd/display: Use HW lock mgr for PSR1"This reverts commita2b5a9956269 ("drm/amd/display: Use HW lock mgr for PSR1")Because it may cause system hang while connect with two edp panel.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: xilinx_uartps: split sysrq handlinglockdep detects the following circular locking dependency:CPU 0 CPU 1========================== ============================cdns_uart_isr() printk() uart_port_lock(port) console_lock() cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock()The fixed commit attempts to avoid this situation by only taking theport lock in cdns_uart_console_write if port->sysrq unset. However, if(as shown above) cdns_uart_console_write runs before port->sysrq is set,then it will try to take the port lock anyway. This may result in adeadlock.Fix this by splitting sysrq handling into two parts. We use the preparehelper under the port lock and defer handling until we release the lock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: omap: use threaded IRQ for LCD DMAWhen using touchscreen and framebuffer, Nokia 770 crashes easily with: BUG: scheduling while atomic: irq/144-ads7846/82/0x00010000 Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2 Hardware name: Nokia 770 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x54/0x5c dump_stack_lvl from __schedule_bug+0x50/0x70 __schedule_bug from __schedule+0x4d4/0x5bc __schedule from schedule+0x34/0xa0 schedule from schedule_preempt_disabled+0xc/0x10 schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4 __mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4 clk_prepare_lock from clk_set_rate+0x18/0x154 clk_set_rate from sossi_read_data+0x4c/0x168 sossi_read_data from hwa742_read_reg+0x5c/0x8c hwa742_read_reg from send_frame_handler+0xfc/0x300 send_frame_handler from process_pending_requests+0x74/0xd0 process_pending_requests from lcd_dma_irq_handler+0x50/0x74 lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130 __handle_irq_event_percpu from handle_irq_event+0x28/0x68 handle_irq_event from handle_level_irq+0x9c/0x170 handle_level_irq from generic_handle_domain_irq+0x2c/0x3c generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c generic_handle_arch_irq from call_with_stack+0x1c/0x24 call_with_stack from __irq_svc+0x94/0xa8 Exception stack(0xc5255da0 to 0xc5255de8) 5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248 5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94 5de0: 60000013 ffffffff __irq_svc from clk_prepare_lock+0x4c/0xe4 clk_prepare_lock from clk_get_rate+0x10/0x74 clk_get_rate from uwire_setup_transfer+0x40/0x180 uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664 spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498 __spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8 __spi_sync from spi_sync+0x24/0x40 spi_sync from ads7846_halfd_read_state+0x5c/0x1c0 ads7846_halfd_read_state from ads7846_irq+0x58/0x348 ads7846_irq from irq_thread_fn+0x1c/0x78 irq_thread_fn from irq_thread+0x120/0x228 irq_thread from kthread+0xc8/0xe8 kthread from ret_from_fork+0x14/0x28As a quick fix, switch to a threaded IRQ which provides a stable system.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: Drop unmanaged ELP metric workerThe ELP worker needs to calculate new metric values for all neighbors"reachable" over an interface. Some of the used metric sources requirelocks which might need to sleep. This sleep is incompatible with the RCUlist iterator used for the recorded neighbors. The initial approach to workaround of this problem was to queue another work item per neighbor and thenrun this in a new context.Even when this solved the RCU vs might_sleep() conflict, it has a majorproblems: Nothing was stopping the work item in case it is not neededanymore - for example because one of the related interfaces was removed orthe batman-adv module was unloaded - resulting in potential invalid memoryaccesses.Directly canceling the metric worker also has various problems:* cancel_work_sync for a to-be-deactivated interface is called with rtnl_lock held. But the code in the ELP metric worker also tries to use rtnl_lock() - which will never return in this case. This also means that cancel_work_sync would never return because it is waiting for the worker to finish.* iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must "stop" all still running workers)The better approch is to get rid of the per interface neighbor metricworker and handle everything in the interface worker. The original problemsare solved by:* creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context* only use rcu_trylock inside metric gathering code to avoid a deadlock when the cancel_delayed_work_sync is called in the interface removal code (which is called with the rtnl_lock held)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpu: host1x: Fix a use of uninitialized mutexcommit c8347f915e67 ("gpu: host1x: Fix boot regression for Tegra")caused a use of uninitialized mutex leading to below warning whenCONFIG_DEBUG_MUTEXES and CONFIG_DEBUG_LOCK_ALLOC are enabled.[ 41.662843] ------------[ cut here ]------------[ 41.663012] DEBUG_LOCKS_WARN_ON(lock->magic != lock)[ 41.663035] WARNING: CPU: 4 PID: 794 at kernel/locking/mutex.c:587 __mutex_lock+0x670/0x878[ 41.663458] Modules linked in: rtw88_8822c(+) bluetooth(+) rtw88_pci rtw88_core mac80211 aquantia libarc4 crc_itu_t cfg80211 tegra194_cpufreq dwmac_tegra(+) arm_dsu_pmu stmmac_platform stmmac pcs_xpcs rfkill at24 host1x(+) tegra_bpmp_thermal ramoops reed_solomon fuse loop nfnetlink xfs mmc_block rpmb_core ucsi_ccg ina3221 crct10dif_ce xhci_tegra ghash_ce lm90 sha2_ce sha256_arm64 sha1_ce sdhci_tegra pwm_fan sdhci_pltfm sdhci gpio_keys rtc_tegra cqhci mmc_core phy_tegra_xusb i2c_tegra tegra186_gpc_dma i2c_tegra_bpmp spi_tegra114 dm_mirror dm_region_hash dm_log dm_mod[ 41.665078] CPU: 4 UID: 0 PID: 794 Comm: (udev-worker) Not tainted 6.11.0-29.31_1538613708.el10.aarch64+debug #1[ 41.665838] Hardware name: NVIDIA NVIDIA Jetson AGX Orin Developer Kit/Jetson, BIOS 36.3.0-gcid-35594366 02/26/2024[ 41.672555] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 41.679636] pc : __mutex_lock+0x670/0x878[ 41.683834] lr : __mutex_lock+0x670/0x878[ 41.688035] sp : ffff800084b77090[ 41.691446] x29: ffff800084b77160 x28: ffffdd4bebf7b000 x27: ffffdd4be96b1000[ 41.698799] x26: 1fffe0002308361c x25: 1ffff0001096ee18 x24: 0000000000000000[ 41.706149] x23: 0000000000000000 x22: 0000000000000002 x21: ffffdd4be6e3c7a0[ 41.713500] x20: ffff800084b770f0 x19: ffff00011841b1e8 x18: 0000000000000000[ 41.720675] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720[ 41.728023] x14: 0000000000000000 x13: 0000000000000001 x12: ffff6001a96eaab3[ 41.735375] x11: 1fffe001a96eaab2 x10: ffff6001a96eaab2 x9 : ffffdd4be4838bbc[ 41.742723] x8 : 00009ffe5691554e x7 : ffff000d4b755593 x6 : 0000000000000001[ 41.749985] x5 : ffff000d4b755590 x4 : 1fffe0001d88f001 x3 : dfff800000000000[ 41.756988] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000ec478000[ 41.764251] Call trace:[ 41.766695] __mutex_lock+0x670/0x878[ 41.770373] mutex_lock_nested+0x2c/0x40[ 41.774134] host1x_intr_start+0x54/0xf8 [host1x][ 41.778863] host1x_runtime_resume+0x150/0x228 [host1x][ 41.783935] pm_generic_runtime_resume+0x84/0xc8[ 41.788485] __rpm_callback+0xa0/0x478[ 41.792422] rpm_callback+0x15c/0x1a8[ 41.795922] rpm_resume+0x698/0xc08[ 41.799597] __pm_runtime_resume+0xa8/0x140[ 41.803621] host1x_probe+0x810/0xbc0 [host1x][ 41.807909] platform_probe+0xcc/0x1a8[ 41.811845] really_probe+0x188/0x800[ 41.815347] __driver_probe_device+0x164/0x360[ 41.819810] driver_probe_device+0x64/0x1a8[ 41.823834] __driver_attach+0x180/0x490[ 41.827773] bus_for_each_dev+0x104/0x1a0[ 41.831797] driver_attach+0x44/0x68[ 41.835296] bus_add_driver+0x23c/0x4e8[ 41.839235] driver_register+0x15c/0x3a8[ 41.843170] __platform_register_drivers+0xa4/0x208[ 41.848159] tegra_host1x_init+0x4c/0xff8 [host1x][ 41.853147] do_one_initcall+0xd4/0x380[ 41.856997] do_init_module+0x1dc/0x698[ 41.860758] load_module+0xc70/0x1300[ 41.864435] __do_sys_init_module+0x1a8/0x1d0[ 41.868721] __arm64_sys_init_module+0x74/0xb0[ 41.873183] invoke_syscall.constprop.0+0xdc/0x1e8[ 41.877997] do_el0_svc+0x154/0x1d0[ 41.881671] el0_svc+0x54/0x140[ 41.884820] el0t_64_sync_handler+0x120/0x130[ 41.889285] el0t_64_sync+0x1a4/0x1a8[ 41.892960] irq event stamp: 69737[ 41.896370] hardirqs last enabled at (69737): [] _raw_spin_unlock_irqrestore+0x44/0xe8[ 41.905739] hardirqs last disabled at (69736):---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") sets thepolicy that all PCIe ports are allowed to use D3. When the system issuspended if the port is not power manageable by the platform and won't beused for wakeup via a PME this sets up the policy for these ports to gointo D3hot.This policy generally makes sense from an OSPM perspective but it leads toproblems with wakeup from suspend on the TUXEDO Sirius 16 Gen 1 with aspecific old BIOS. This manifests as a system hang.On the affected Device + BIOS combination, add a quirk for the root port ofthe problematic controller to ensure that these root ports are not put intoD3hot at suspend.This patch is based on https://lore.kernel.org/linux-pci/20230708214457.1229-2-mario.limonciello@amd.combut with the added condition both in the documentation and in the code toapply only to the TUXEDO Sirius 16 Gen 1 with a specific old BIOS and onlythe affected root ports.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: don't revert iter for -EIOCBQUEUEDblkdev_read_iter() has a few odd checks, like gating the position andcount adjustment on whether or not the result is bigger-than-or-equal tozero (where bigger than makes more sense), and not checking the returnvalue of blkdev_direct_IO() before doing an iov_iter_revert(). Thelatter can lead to attempting to revert with a negative value, whichwhen passed to iov_iter_revert() as an unsigned value will lead tothrowing a WARN_ON() because unroll is bigger than MAX_RW_COUNT.Be sane and don't revert for -EIOCBQUEUED, like what is done in otherspots.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:seccomp: passthrough uretprobe systemcall without filteringWhen attaching uretprobes to processes running inside docker, the attachedprocess is segfaulted when encountering the retprobe.The reason is that now that uretprobe is a system call the default seccompfilters in docker block it as they only allow a specific set of knownsyscalls. This is true for other userspace applications which use seccompto control their syscall surface.Since uretprobe is a "kernel implementation detail" system call which isnot used by userspace application code directly, it is impractical andthere's very little point in forcing all userspace applications toexplicitly allow it in order to avoid crashing tracked processes.Pass this systemcall through seccomp without depending on configuration.Note: uretprobe is currently only x86_64 and isn't expected to ever besupported in i386.[kees: minimized changes for easier backporting, tweaked commit log]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_midi: fix MIDI Streaming descriptor lengthsWhile the MIDI jacks are configured correctly, and the MIDIStreamingendpoint descriptors are filled with the correct information,bNumEmbMIDIJack and bLength are set incorrectly in these descriptors.This does not matter when the numbers of in and out ports are equal, butwhen they differ the host will receive broken descriptors withuninitialized stack memory leaking into the descriptor for whichevervalue is smaller.The precise meaning of "in" and "out" in the port counts is not clearlydefined and can be confusing. But elsewhere the driver consistentlyuses this to match the USB meaning of IN and OUT viewed from the host,so that "in" ports send data to the host and "out" ports receive datafrom it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/kbuf: reallocate buf lists on upgradeIORING_REGISTER_PBUF_RING can reuse an old struct io_buffer_list if itwas created for legacy selected buffer and has been emptied. It violatesthe requirement that most of the field should stay stable after publish.Always reallocate it instead.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:thermal/netlink: Prevent userspace segmentation fault by adjusting UAPI headerThe intel-lpmd tool [1], which uses the THERMAL_GENL_ATTR_CPU_CAPABILITYattribute to receive HFI events from kernel space, encounters asegmentation fault after commit 1773572863c4 ("thermal: netlink: Add thecommands and the events for the thresholds").The issue arises because the THERMAL_GENL_ATTR_CPU_CAPABILITY raw valuewas changed while intel_lpmd still uses the old value.Although intel_lpmd can be updated to check the THERMAL_GENL_VERSION anduse the appropriate THERMAL_GENL_ATTR_CPU_CAPABILITY value, the commititself is questionable.The commit introduced a new element in the middle of enum thermal_genl_attr,which affects many existing attributes and introduces potential risksand unnecessary maintenance burdens for userspace thermal netlink eventusers.Solve the issue by moving the newly introducedTHERMAL_GENL_ATTR_TZ_PREV_TEMP attribute to the end of theenum thermal_genl_attr. This ensures that all existing thermal genericnetlink attributes remain unaffected.[ rjw: Subject edits ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq/amd-pstate: Fix cpufreq_policy ref countingamd_pstate_update_limits() takes a cpufreq_policy reference but doesn'tdecrement the refcount in one of the exit paths, fix that.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:amdkfd: properly free gang_ctx_bo when failed to init user queueThe destructor of a gtt bo is declared asvoid amdgpu_amdkfd_free_gtt_mem(struct amdgpu_device *adev, void **mem_obj);Which takes void** as the second parameter.GCC allows passing void* to the function because void* can be implicitlycasted to any other types, so it can pass compiling.However, passing this void* parameter into the function'sexecution process(which expects void** and dereferencing void**)will result in errors.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/panthor: avoid garbage value in panthor_ioctl_dev_query()'priorities_info' is uninitialized, and the uninitialized value is copiedto user object when calling PANTHOR_UOBJ_SET(). Using memset to initialize'priorities_info' to avoid this garbage value problem.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Add check for next_buffer in receive_encrypted_standard()Add check for the return value of cifs_buf_get() and cifs_small_buf_get()in receive_encrypted_standard() to prevent null pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:acct: perform last write from workqueueIn [1] it was reported that the acct(2) system call can be used totrigger NULL deref in cases where it is set to write to a file thattriggers an internal lookup. This can e.g., happen when pointing acc(2)to /sys/power/resume. At the point the where the write to this filehappens the calling task has already exited and called exit_fs(). Alookup will thus trigger a NULL-deref when accessing current->fs.Reorganize the code so that the the final write happens from theworkqueue but with the caller's credentials. This preserves the(strange) permission model and has almost no regression risk.This api should stop to exist though.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: stream-ipc: Check for cstream nullity in sof_ipc_msg_data()The nullity of sps->cstream should be checked similarly as it is done insof_set_stream_data_offset() function.Assuming that it is not NULL if sps->stream is NULL is incorrect and canlead to NULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfp: bpf: Add check for nfp_app_ctrl_msg_alloc()Add check for the return value of nfp_app_ctrl_msg_alloc() innfp_bpf_cmsg_alloc() to prevent null pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gt: Use spin_lock_irqsave() in interruptible contextspin_lock/unlock() functions used in interrupt contexts couldresult in a deadlock, as seen in GitLab issue #13399,which occurs when interrupt comes in while holding a lock.Try to remedy the problem by saving irq state before spin lockacquisition.v2: add irqs' state save/restore calls to all locks/unlocks in signal_irq_work() execution (Maciej)v3: use with spin_lock_irqsave() in guc_lrc_desc_unpin() instead of other lock/unlock calls and add Fixes and Cc tags (Tvrtko); change title and commit message(cherry picked from commit c088387ddd6482b40f21ccf23db1125e8fa4af7e)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet: Fix crash when a namespace is disabledThe namespace percpu counter protects pending I/O, and we canonly safely diable the namespace once the counter drop to zero.Otherwise we end up with a crash when running blktests/nvme/058(eg for loop transport):[ 2352.930426] [ T53909] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI[ 2352.930431] [ T53909] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f][ 2352.930434] [ T53909] CPU: 3 UID: 0 PID: 53909 Comm: kworker/u16:5 Tainted: G W 6.13.0-rc6 #232[ 2352.930438] [ T53909] Tainted: [W]=WARN[ 2352.930440] [ T53909] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014[ 2352.930443] [ T53909] Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop][ 2352.930449] [ T53909] RIP: 0010:blkcg_set_ioprio+0x44/0x180as the queue is already torn down when calling submit_bio();So we need to init the percpu counter in nvmet_ns_enable(), andwait for it to drop to zero in nvmet_ns_disable() to avoid havingI/O pending after the namespace has been disabled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix softlockup in arena_map_free on 64k page kernelOn an aarch64 kernel with CONFIG_PAGE_SIZE_64KB=y,arena_htab tests cause a segmentation fault and soft lockup.The same failure is not observed with 4k pages on aarch64.It turns out arena_map_free() is callingapply_to_existing_page_range() with the address returned bybpf_arena_get_kern_vm_start(). If this address is not page-alignedthe code ends up calling apply_to_pte_range() with that unalignedaddress causing soft lockup.Fix it by round up GUARD_SZ to PAGE_SIZE << 1 so that thedivision by 2 in bpf_arena_get_kern_vm_start() returnsa page-aligned value.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: Add rx_skb of kfree_skb to raw_tp_null_args[].Yan Zhai reported a BPF prog could trigger a null-ptr-deref [0]in trace_kfree_skb if the prog does not check if rx_sk is NULL.Commit c53795d48ee8 ("net: add rx_sk to trace_kfree_skb") addedrx_sk to trace_kfree_skb, but rx_sk is optional and could be NULL.Let's add kfree_skb to raw_tp_null_args[] to let the BPF verifiervalidate such a prog and prevent the issue.Now we fail to load such a prog: libbpf: prog 'drop': -- BEGIN PROG LOAD LOG -- 0: R1=ctx() R10=fp0 ; int BPF_PROG(drop, struct sk_buff *skb, void *location, @ kfree_skb_sk_null.bpf.c:21 0: (79) r3 = *(u64 *)(r1 +24) func 'kfree_skb' arg3 has btf_id 5253 type STRUCT 'sock' 1: R1=ctx() R3_w=trusted_ptr_or_null_sock(id=1) ; bpf_printk("sk: %d, %d\n", sk, sk->__sk_common.skc_family); @ kfree_skb_sk_null.bpf.c:24 1: (69) r4 = *(u16 *)(r3 +16) R3 invalid mem access 'trusted_ptr_or_null_' processed 2 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 -- END PROG LOAD LOG --Note this fix requires commit 838a10bd2ebf ("bpf: Augment raw_tparguments with PTR_MAYBE_NULL").[0]:BUG: kernel NULL pointer dereference, address: 0000000000000010 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 0 P4D 0PREEMPT SMPRIP: 0010:bpf_prog_5e21a6db8fcff1aa_drop+0x10/0x2dCall Trace: ? __die+0x1f/0x60 ? page_fault_oops+0x148/0x420 ? search_bpf_extables+0x5b/0x70 ? fixup_exception+0x27/0x2c0 ? exc_page_fault+0x75/0x170 ? asm_exc_page_fault+0x22/0x30 ? bpf_prog_5e21a6db8fcff1aa_drop+0x10/0x2d bpf_trace_run4+0x68/0xd0 ? unix_stream_connect+0x1f4/0x6f0 sk_skb_reason_drop+0x90/0x120 unix_stream_connect+0x1f4/0x6f0 __sys_connect+0x7f/0xb0 __x64_sys_connect+0x14/0x20 do_syscall_64+0x47/0xc30 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: avoid holding freeze_mutex during mmap operationWe use map->freeze_mutex to prevent races between map_freeze() andmemory mapping BPF map contents with writable permissions. The way wenaively do this means we'll hold freeze_mutex for entire duration of allthe mm and VMA manipulations, which is completely unnecessary. This canpotentially also lead to deadlocks, as reported by syzbot in [0].So, instead, hold freeze_mutex only during writeability checks, bump(proactively) "write active" count for the map, unlock the mutex andproceed with mmap logic. And only if something went wrong during mmaplogic, then undo that "write active" counter increment. [0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sockmap, vsock: For connectible sockets allow only connectedsockmap expects all vsocks to have a transport assigned, which is expressedin vsock_proto::psock_update_sk_prot(). However, there is an edge casewhere an unconnected (connectible) socket may lose its previously assignedtransport. This is handled with a NULL check in the vsock/BPF recv path.Another design detail is that listening vsocks are not supposed to have anytransport assigned at all. Which implies they are not supported by thesockmap. But this is complicated by the fact that a socket, beforeswitching to TCP_LISTEN, may have had some transport assigned during afailed connect() attempt. Hence, we may end up with a listening vsock in asockmap, which blows up quickly:KASAN: null-ptr-deref in range [0x0000000000000120-0x0000000000000127]CPU: 7 UID: 0 PID: 56 Comm: kworker/7:0 Not tainted 6.14.0-rc1+Workqueue: vsock-loopback vsock_loopback_workRIP: 0010:vsock_read_skb+0x4b/0x90Call Trace: sk_psock_verdict_data_ready+0xa4/0x2e0 virtio_transport_recv_pkt+0x1ca8/0x2acc vsock_loopback_work+0x27d/0x3f0 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x35a/0x700 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30For connectible sockets, instead of relying solely on the state ofvsk->transport, tell sockmap to only allow those representing establishedconnections. This aligns with the behaviour for AF_INET and AF_UNIX.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/ism: add release function for struct deviceAccording to device_release() in /drivers/base/core.c,a device without a release function is a broken deviceand must be fixed.The current code directly frees the device after calling device_add()without waiting for other kernel parts to release their references.Thus, a reference could still be held to a struct device,e.g., by sysfs, leading to potential use-after-freeissues if a proper release function is not set.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: cls_api: fix error handling causing NULL dereferencetcf_exts_miss_cookie_base_alloc() calls xa_alloc_cyclic() which canreturn 1 if the allocation succeeded after wrapping. This was treated asan error, with value 1 returned to caller tcf_exts_init_ex() which setsexts->actions to NULL and returns 1 to caller fl_change().fl_change() treats err == 1 as success, calling tcf_exts_validate_ex()which calls tcf_action_init() with exts->actions as argument, where itis dereferenced.Example trace:BUG: kernel NULL pointer dereference, address: 0000000000000000CPU: 114 PID: 16151 Comm: handler114 Kdump: loaded Not tainted 5.14.0-503.16.1.el9_5.x86_64 #1RIP: 0010:tcf_action_init+0x1f8/0x2c0Call Trace: tcf_action_init+0x1f8/0x2c0 tcf_exts_validate_ex+0x175/0x190 fl_change+0x537/0x1120 [cls_flower]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:geneve: Fix use-after-free in geneve_find_dev().syzkaller reported a use-after-free in geneve_find_dev() [0]without repro.geneve_configure() links struct geneve_dev.next tonet_generic(net, geneve_net_id)->geneve_list.The net here could differ from dev_net(dev) if IFLA_NET_NS_PID,IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set.When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finallycalls unregister_netdevice_queue() for each dev in the netns,and later the dev is freed.However, its geneve_dev.next is still linked to the backend UDPsocket netns.Then, use-after-free will occur when another geneve dev is createdin the netns.Let's call geneve_dellink() instead in geneve_destroy_tunnels().[0]:BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline]BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3dHardware name: linux,dummy-virt (DT)Call trace: show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x16c/0x6f0 mm/kasan/report.c:489 kasan_report+0xc0/0x120 mm/kasan/report.c:602 __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379 geneve_find_dev drivers/net/geneve.c:1295 [inline] geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634 rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:713 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568 ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622 __sys_sendmsg net/socket.c:2654 [inline] __do_sys_sendmsg net/socket.c:2659 [inline] __se_sys_sendmsg net/socket.c:2657 [inline] __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600Allocated by task 13247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x68 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4298 [inline] __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645 alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470 rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_n---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: gadget: f_midi: f_midi_complete to call queue_workWhen using USB MIDI, a lock is attempted to be acquired twice through are-entrant call to f_midi_transmit, causing a deadlock.Fix it by using queue_work() to schedule the inner f_midi_transmit() viaa high priority work queue from the completion handler.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/zswap: fix inconsistency when zswap_store_page() failsCommit b7c0ccdfbafd ("mm: zswap: support large folios in zswap_store()")skips charging any zswap entries when it failed to zswap the entire folio.However, when some base pages are zswapped but it failed to zswap theentire folio, the zswap operation is rolled back. When freeing zswapentries for those pages, zswap_entry_free() uncharges the zswap entriesthat were not previously charged, causing zswap charging to becomeinconsistent.This inconsistency triggers two warnings with following steps: # On a machine with 64GiB of RAM and 36GiB of zswap $ stress-ng --bigheap 2 # wait until the OOM-killer kills stress-ng $ sudo reboot The two warnings are: in mm/memcontrol.c:163, function obj_cgroup_release(): WARN_ON_ONCE(nr_bytes & (PAGE_SIZE - 1)); in mm/page_counter.c:60, function page_counter_cancel(): if (WARN_ONCE(new < 0, "page_counter underflow: %ld nr_pages=%lu\n", new, nr_pages))zswap_stored_pages also becomes inconsistent in the same way.As suggested by Kanchana, increment zswap_stored_pages and charge zswapentries within zswap_store_page() when it succeeds. This way,zswap_entry_free() will decrement the counter and uncharge the entrieswhen it failed to zswap the entire folio.While this could potentially be optimized by batching objcg charging andincrementing the counter, let's focus on fixing the bug this time andleave the optimization for later after some evaluation.After resolving the inconsistency, the warnings disappear.[42.hyeyoo@gmail.com: refactor zswap_store_page()]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/migrate_device: don't add folio to be freed to LRU in migrate_device_finalize()If migration succeeded, we calledfolio_migrate_flags()->mem_cgroup_migrate() to migrate the memcg from theold to the new folio. This will set memcg_data of the old folio to 0.Similarly, if migration failed, memcg_data of the dst folio is left unset.If we call folio_putback_lru() on such folios (memcg_data == 0), we willadd the folio to be freed to the LRU, making memcg code unhappy. Runningthe hmm selftests: # ./hmm-tests ... # RUN hmm.hmm_device_private.migrate ... [ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00 [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff) [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9 [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000 [ 102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled()) [ 102.087230][T14893] ------------[ cut here ]------------ [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.090478][T14893] Modules linked in: [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151 [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.096104][T14893] Code: ... [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293 [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426 [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880 [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8 [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000 [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0 [ 102.113478][T14893] PKRU: 55555554 [ 102.114172][T14893] Call Trace: [ 102.114805][T14893] [ 102.115397][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.116547][T14893] ? __warn.cold+0x110/0x210 [ 102.117461][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.118667][T14893] ? report_bug+0x1b9/0x320 [ 102.119571][T14893] ? handle_bug+0x54/0x90 [ 102.120494][T14893] ? exc_invalid_op+0x17/0x50 [ 102.121433][T14893] ? asm_exc_invalid_op+0x1a/0x20 [ 102.122435][T14893] ? __wake_up_klogd.part.0+0x76/0xd0 [ 102.123506][T14893] ? dump_page+0x4f/0x60 [ 102.124352][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.125500][T14893] folio_batch_move_lru+0xd4/0x200 [ 102.126577][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.127505][T14893] __folio_batch_add_and_move+0x391/0x720 [ 102.128633][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.129550][T14893] folio_putback_lru+0x16/0x80 [ 102.130564][T14893] migrate_device_finalize+0x9b/0x530 [ 102.131640][T14893] dmirror_migrate_to_device.constprop.0+0x7c5/0xad0 [ 102.133047][T14893] dmirror_fops_unlocked_ioctl+0x89b/0xc80Likely, nothing else goes wrong: putting the last folio reference willremove the folio from the LRU again. So besides memcg complaining, addingthe folio to be freed to the LRU is just an unnecessary step.The new flow resembles what we have in migrate_folio_move(): add the dstto the lru, rem---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drop_monitor: fix incorrect initialization orderSyzkaller reports the following bug:BUG: spinlock bad magic on CPU#1, syz-executor.0/7995 lock: 0xffff88805303f3e0, .magic: 00000000, .owner: /-1, .owner_cpu: 0CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x119/0x179 lib/dump_stack.c:118 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline] _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159 reset_per_cpu_data+0xe6/0x240 [drop_monitor] net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497 genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x157/0x190 net/socket.c:663 ____sys_sendmsg+0x712/0x870 net/socket.c:2378 ___sys_sendmsg+0xf8/0x170 net/socket.c:2432 __sys_sendmsg+0xea/0x1b0 net/socket.c:2461 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x62/0xc7RIP: 0033:0x7f3f9815aee9Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768If drop_monitor is built as a kernel module, syzkaller may have timeto send a netlink NET_DM_CMD_START message during the module loading.This will call the net_dm_monitor_start() function that usesa spinlock that has not yet been initialized.To fix this, let's place resource initialization above the registrationof a generic netlink family.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: prevent opcode speculationsqe->opcode is used for different tables, make sure we santitise itagainst speculations.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: drop secpath at the same time as we currently drop dstXiumei reported hitting the WARN in xfrm6_tunnel_net_exit whilerunning tests that boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netnsThe xfrm_state found on spi_byaddr was not deleted at the time wedelete the netns, because we still have a reference on it. Thislingering reference comes from a secpath (which holds a ref on thexfrm_state), which is still attached to an skb. This skb is notleaked, it ends up on sk_receive_queue and then gets defer-free'd byskb_attempt_defer_free.The problem happens when we defer freeing an skb (push it on one CPU'sdefer_list), and don't flush that list before the netns is deleted. Inthat case, we still have a reference on the xfrm_state that we don'texpect at this point.We already drop the skb's dst in the TCP receive path when it's nolonger needed, so let's also drop the secpath. At this point,tcp_filter has already called into the LSM hooks that may require thesecpath, so it should not be needed anymore. However, in some of thoseplaces, the MPTCP extension has just been attached to the skb, so wecannot simply drop all extensions.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl().Brad Spengler reported the list_del() corruption splat ingtp_net_exit_batch_rtnl(). [0]Commit eb28fd76c0a0 ("gtp: Destroy device along with udp socket's netnsdismantle.") added the for_each_netdev() loop in gtp_net_exit_batch_rtnl()to destroy devices in each netns as done in geneve and ip tunnels.However, this could trigger ->dellink() twice for the same device during->exit_batch_rtnl().Say we have two netns A & B and gtp device B that resides in netns B butwhose UDP socket is in netns A. 1. cleanup_net() processes netns A and then B. 2. gtp_net_exit_batch_rtnl() finds the device B while iterating netns A's gn->gtp_dev_list and calls ->dellink(). [ device B is not yet unlinked from netns B as unregister_netdevice_many() has not been called. ] 3. gtp_net_exit_batch_rtnl() finds the device B while iterating netns B's for_each_netdev() and calls ->dellink().gtp_dellink() cleans up the device's hash table, unlinks the dev fromgn->gtp_dev_list, and calls unregister_netdevice_queue().Basically, calling gtp_dellink() multiple times is fine unlessCONFIG_DEBUG_LIST is enabled.Let's remove for_each_netdev() in gtp_net_exit_batch_rtnl() anddelegate the destruction to default_device_exit_batch() as donein bareudp.[0]:list_del corruption, ffff8880aaa62c00->next (autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]) is LIST_POISON1 (ffffffffffffff02) (prev is 0xffffffffffffff04)kernel BUG at lib/list_debug.c:58!Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASANCPU: 1 UID: 0 PID: 1804 Comm: kworker/u8:7 Tainted: G T 6.12.13-grsec-full-20250211091339 #1Tainted: [T]=RANDSTRUCTHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: netns cleanup_netRIP: 0010:[] __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58Code: c2 76 91 31 c0 e8 9f b1 f7 fc 0f 0b 4d 89 f0 48 c7 c1 02 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 e0 c2 76 91 31 c0 e8 7f b1 f7 fc <0f> 0b 4d 89 e8 48 c7 c1 04 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 60RSP: 0018:fffffe8040b4fbd0 EFLAGS: 00010283RAX: 00000000000000cc RBX: dffffc0000000000 RCX: ffffffff818c4054RDX: ffffffff84947381 RSI: ffffffff818d1512 RDI: 0000000000000000RBP: ffff8880aaa62c00 R08: 0000000000000001 R09: fffffbd008169f32R10: fffffe8040b4f997 R11: 0000000000000001 R12: a1988d84f24943e4R13: ffffffffffffff02 R14: ffffffffffffff04 R15: ffff8880aaa62c08RBX: kasan shadow of 0x0RCX: __wake_up_klogd.part.0+0x74/0xe0 kernel/printk/printk.c:4554RDX: __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58RSI: vprintk+0x72/0x100 kernel/printk/printk_safe.c:71RBP: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]RSP: process kstack fffffe8040b4fbd0+0x7bd0/0x8000 [kworker/u8:7+netns 1804 ]R09: kasan shadow of process kstack fffffe8040b4f990+0x7990/0x8000 [kworker/u8:7+netns 1804 ]R10: process kstack fffffe8040b4f997+0x7997/0x8000 [kworker/u8:7+netns 1804 ]R15: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc08/0x1000 [slab object]FS: 0000000000000000(0000) GS:ffff888116000000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000748f5372c000 CR3: 0000000015408000 CR4: 00000000003406f0 shadow CR4: 00000000003406f0Stack: 0000000000000000 ffffffff8a0c35e7 ffffffff8a0c3603 ffff8880aaa62c00 ffff8880aaa62c00 0000000000000004 ffff88811145311c 0000000000000005 0000000000000001 ffff8880aaa62000 fffffe8040b4fd40 ffffffff8a0c360dCall Trace: [] __list_del_entry_valid include/linux/list.h:131 [inline] fffffe8040b4fc28 [] __list_del_entry include/linux/list.h:248 [inline] fffffe8040b4fc28 [] list_del include/linux/list.h:262 [inl---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOCErhard reported the following KASAN hit while booting his PowerMac G4with a KASAN-enabled kernel 6.13-rc6: BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 Write of size 8 at addr f1000000 by task chronyd/1293 CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G W 6.13.0-rc6-PMacG4 #2 Tainted: [W]=WARN Hardware name: PowerMac3,6 7455 0x80010303 PowerMac Call Trace: [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable) [c24375b0] [c0504998] print_report+0xdc/0x504 [c2437610] [c050475c] kasan_report+0xf8/0x108 [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8 [c24376c0] [c004c014] patch_instructions+0x15c/0x16c [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478 [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14 [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4 [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890 [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420 [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c --- interrupt: c00 at 0x5a1274 NIP: 005a1274 LR: 006a3b3c CTR: 005296c8 REGS: c2437f40 TRAP: 0c00 Tainted: G W (6.13.0-rc6-PMacG4) MSR: 0200f932 CR: 24004422 XER: 00000000 GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932 GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57 GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002 GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001 NIP [005a1274] 0x5a1274 LR [006a3b3c] 0x6a3b3c --- interrupt: c00 The buggy address belongs to the virtual mapping at [f1000000, f1002000) created by: text_area_cpu_up+0x20/0x190 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30 flags: 0x80000000(zone=2) raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001 raw: 00000000 page dumped because: kasan: bad access detected Memory state around the buggy address: f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ==================================================================f8 corresponds to KASAN_VMALLOC_INVALID which means the area is notinitialised hence not supposed to be used yet.Powerpc text patching infrastructure allocates a virtual memory areausing get_vm_area() and flags it as VM_ALLOC. But that flag is meantto be used for vmalloc() and vmalloc() allocated memory is notsupposed to be used before a call to __vmalloc_node_range() which isnever called for that area.That went undetected until commit e4137f08816b ("mm, kasan, kmsan:instrument copy_from/to_kernel_nofault")The area allocated by text_area_cpu_up() is not vmalloc memory, it ismapped directly on demand when needed by map_kernel_page(). There isno VM flag corresponding to such usage, so just pass no flag. That waythe area will be unpoisonned and usable immediately.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, test_run: Fix use-after-free issue in eth_skb_pkt_type()KMSAN reported a use-after-free issue in eth_skb_pkt_type()[1]. Thecause of the issue was that eth_skb_pkt_type() accessed skb's datathat didn't contain an Ethernet header. This occurs whenbpf_prog_test_run_xdp() passes an invalid value as the user_dataargument to bpf_test_init().Fix this by returning an error when user_data is less than ETH_HLEN inbpf_test_init(). Additionally, remove the check for "if (user_size >size)" as it is unnecessary.[1]BUG: KMSAN: use-after-free in eth_skb_pkt_type include/linux/etherdevice.h:627 [inline]BUG: KMSAN: use-after-free in eth_type_trans+0x4ee/0x980 net/ethernet/eth.c:165 eth_skb_pkt_type include/linux/etherdevice.h:627 [inline] eth_type_trans+0x4ee/0x980 net/ethernet/eth.c:165 __xdp_build_skb_from_frame+0x5a8/0xa50 net/core/xdp.c:635 xdp_recv_frames net/bpf/test_run.c:272 [inline] xdp_test_run_batch net/bpf/test_run.c:361 [inline] bpf_test_run_xdp_live+0x2954/0x3330 net/bpf/test_run.c:390 bpf_prog_test_run_xdp+0x148e/0x1b10 net/bpf/test_run.c:1318 bpf_prog_test_run+0x5b7/0xa30 kernel/bpf/syscall.c:4371 __sys_bpf+0x6a6/0xe20 kernel/bpf/syscall.c:5777 __do_sys_bpf kernel/bpf/syscall.c:5866 [inline] __se_sys_bpf kernel/bpf/syscall.c:5864 [inline] __x64_sys_bpf+0xa4/0xf0 kernel/bpf/syscall.c:5864 x64_sys_call+0x2ea0/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: free_pages_prepare mm/page_alloc.c:1056 [inline] free_unref_page+0x156/0x1320 mm/page_alloc.c:2657 __free_pages+0xa3/0x1b0 mm/page_alloc.c:4838 bpf_ringbuf_free kernel/bpf/ringbuf.c:226 [inline] ringbuf_map_free+0xff/0x1e0 kernel/bpf/ringbuf.c:235 bpf_map_free kernel/bpf/syscall.c:838 [inline] bpf_map_free_deferred+0x17c/0x310 kernel/bpf/syscall.c:862 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa2b/0x1b60 kernel/workqueue.c:3310 worker_thread+0xedf/0x1550 kernel/workqueue.c:3391 kthread+0x535/0x6b0 kernel/kthread.c:389 ret_from_fork+0x6e/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244CPU: 1 UID: 0 PID: 17276 Comm: syz.1.16450 Not tainted 6.12.0-05490-g9bb88c659673 #8Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: allow small head cache usage with large MAX_SKB_FRAGS valuesSabrina reported the following splat: WARNING: CPU: 0 PID: 1 at net/core/dev.c:6935 netif_napi_add_weight_locked+0x8f2/0xba0 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.14.0-rc1-net-00092-g011b03359038 #996 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:netif_napi_add_weight_locked+0x8f2/0xba0 Code: e8 c3 e6 6a fe 48 83 c4 28 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc c7 44 24 10 ff ff ff ff e9 8f fb ff ff e8 9e e6 6a fe <0f> 0b e9 d3 fe ff ff e8 92 e6 6a fe 48 8b 04 24 be ff ff ff ff 48 RSP: 0000:ffffc9000001fc60 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88806ce48128 RCX: 1ffff11001664b9e RDX: ffff888008f00040 RSI: ffffffff8317ca42 RDI: ffff88800b325cb6 RBP: ffff88800b325c40 R08: 0000000000000001 R09: ffffed100167502c R10: ffff88800b3a8163 R11: 0000000000000000 R12: ffff88800ac1c168 R13: ffff88800ac1c168 R14: ffff88800ac1c168 R15: 0000000000000007 FS: 0000000000000000(0000) GS:ffff88806ce00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff888008201000 CR3: 0000000004c94001 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: gro_cells_init+0x1ba/0x270 xfrm_input_init+0x4b/0x2a0 xfrm_init+0x38/0x50 ip_rt_init+0x2d7/0x350 ip_init+0xf/0x20 inet_init+0x406/0x590 do_one_initcall+0x9d/0x2e0 do_initcalls+0x23b/0x280 kernel_init_freeable+0x445/0x490 kernel_init+0x20/0x1d0 ret_from_fork+0x46/0x80 ret_from_fork_asm+0x1a/0x30 irq event stamp: 584330 hardirqs last enabled at (584338): [] __up_console_sem+0x77/0xb0 hardirqs last disabled at (584345): [] __up_console_sem+0x5c/0xb0 softirqs last enabled at (583242): [] netlink_insert+0x14d/0x470 softirqs last disabled at (583754): [] netif_napi_add_weight_locked+0x77d/0xba0on kernel built with MAX_SKB_FRAGS=45, where SKB_WITH_OVERHEAD(1024)is smaller than GRO_MAX_HEAD.Such built additionally contains the revert of the single page frag cacheso that napi_get_frags() ends up using the page frag allocator, triggeringthe splat.Note that the underlying issue is independent from the mentionedrevert; address it ensuring that the small head cache will fit either TCPand GRO allocation and updating napi_alloc_skb() and __netdev_alloc_skb()to select kmalloc() usage for any allocation fitting such cache.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/code-patching: Disable KASAN report during patching via temporary mmErhard reports the following KASAN hit on Talos II (power9) with kernel 6.13:[ 12.028126] ==================================================================[ 12.028198] BUG: KASAN: user-memory-access in copy_to_kernel_nofault+0x8c/0x1a0[ 12.028260] Write of size 8 at addr 0000187e458f2000 by task systemd/1[ 12.028346] CPU: 87 UID: 0 PID: 1 Comm: systemd Tainted: G T 6.13.0-P9-dirty #3[ 12.028408] Tainted: [T]=RANDSTRUCT[ 12.028446] Hardware name: T2P9D01 REV 1.01 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV[ 12.028500] Call Trace:[ 12.028536] [c000000008dbf3b0] [c000000001656a48] dump_stack_lvl+0xbc/0x110 (unreliable)[ 12.028609] [c000000008dbf3f0] [c0000000006e2fc8] print_report+0x6b0/0x708[ 12.028666] [c000000008dbf4e0] [c0000000006e2454] kasan_report+0x164/0x300[ 12.028725] [c000000008dbf600] [c0000000006e54d4] kasan_check_range+0x314/0x370[ 12.028784] [c000000008dbf640] [c0000000006e6310] __kasan_check_write+0x20/0x40[ 12.028842] [c000000008dbf660] [c000000000578e8c] copy_to_kernel_nofault+0x8c/0x1a0[ 12.028902] [c000000008dbf6a0] [c0000000000acfe4] __patch_instructions+0x194/0x210[ 12.028965] [c000000008dbf6e0] [c0000000000ade80] patch_instructions+0x150/0x590[ 12.029026] [c000000008dbf7c0] [c0000000001159bc] bpf_arch_text_copy+0x6c/0xe0[ 12.029085] [c000000008dbf800] [c000000000424250] bpf_jit_binary_pack_finalize+0x40/0xc0[ 12.029147] [c000000008dbf830] [c000000000115dec] bpf_int_jit_compile+0x3bc/0x930[ 12.029206] [c000000008dbf990] [c000000000423720] bpf_prog_select_runtime+0x1f0/0x280[ 12.029266] [c000000008dbfa00] [c000000000434b18] bpf_prog_load+0xbb8/0x1370[ 12.029324] [c000000008dbfb70] [c000000000436ebc] __sys_bpf+0x5ac/0x2e00[ 12.029379] [c000000008dbfd00] [c00000000043a228] sys_bpf+0x28/0x40[ 12.029435] [c000000008dbfd20] [c000000000038eb4] system_call_exception+0x334/0x610[ 12.029497] [c000000008dbfe50] [c00000000000c270] system_call_vectored_common+0xf0/0x280[ 12.029561] --- interrupt: 3000 at 0x3fff82f5cfa8[ 12.029608] NIP: 00003fff82f5cfa8 LR: 00003fff82f5cfa8 CTR: 0000000000000000[ 12.029660] REGS: c000000008dbfe80 TRAP: 3000 Tainted: G T (6.13.0-P9-dirty)[ 12.029735] MSR: 900000000280f032 CR: 42004848 XER: 00000000[ 12.029855] IRQMASK: 0 GPR00: 0000000000000169 00003fffdcf789a0 00003fff83067100 0000000000000005 GPR04: 00003fffdcf78a98 0000000000000090 0000000000000000 0000000000000008 GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR12: 0000000000000000 00003fff836ff7e0 c000000000010678 0000000000000000 GPR16: 0000000000000000 0000000000000000 00003fffdcf78f28 00003fffdcf78f90 GPR20: 0000000000000000 0000000000000000 0000000000000000 00003fffdcf78f80 GPR24: 00003fffdcf78f70 00003fffdcf78d10 00003fff835c7239 00003fffdcf78bd8 GPR28: 00003fffdcf78a98 0000000000000000 0000000000000000 000000011f547580[ 12.030316] NIP [00003fff82f5cfa8] 0x3fff82f5cfa8[ 12.030361] LR [00003fff82f5cfa8] 0x3fff82f5cfa8[ 12.030405] --- interrupt: 3000[ 12.030444] ==================================================================Commit c28c15b6d28a ("powerpc/code-patching: Use temporary mm forRadix MMU") is inspired from x86 but unlike x86 is doesn't disableKASAN reports during patching. This wasn't a problem at the beginingbecause __patch_mem() is not instrumented.Commit 465cabc97b42 ("powerpc/code-patching: introducepatch_instructions()") use copy_to_kernel_nofault() to copy severalinstructions at once. But when using temporary mm the destination isnot regular kernel memory but a kind of kernel-like memory locatedin user address space. ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: ipc4-topology: Harden loops for looking up ALH copiersOther, non DAI copier widgets could have the same stream name (sname) asthe ALH copier and in that case the copier->data is NULL, no alh_data isattached, which could lead to NULL pointer dereference.We could check for this NULL pointer in sof_ipc4_prepare_copier_module()and avoid the crash, but a similar loop in sof_ipc4_widget_setup_comp_dai()will miscalculate the ALH device count, causing broken audio.The correct fix is to harden the matching logic by making sure that the1. widget is a DAI widget - so dai = w->private is valid2. the dai (and thus the copier) is ALH copier
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tee: optee: Fix supplicant wait loopOP-TEE supplicant is a user-space daemon and it's possible for itbe hung or crashed or killed in the middle of processing an OP-TEERPC call. It becomes more complicated when there is incorrect shutdownordering of the supplicant process vs the OP-TEE client application whichcan eventually lead to system hang-up waiting for the closure of theclient application.Allow the client process waiting in kernel for supplicant response tobe killed rather than indefinitely waiting in an unkillable state. Also,a normal uninterruptible wait should not have resulted in the hung-taskwatchdog getting triggered, but the endless loop would.This fixes issues observed during system reboot/shutdown when supplicantgot hung for some reason or gets crashed/killed which lead to clientgetting hung in an unkillable state. It in turn lead to system being inhung up state requiring hard power off/on to recover.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:efi: Don't map the entire mokvar table to determine its sizeCurrently, when validating the mokvar table, we (re)map the entire tableon each iteration of the loop, adding space as we discover new entries.If the table grows over a certain size, this fails due to limitations ofearly_memmap(), and we get a failure and traceback: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220 ... Call Trace: ? __early_ioremap+0xef/0x220 ? __warn.cold+0x93/0xfa ? __early_ioremap+0xef/0x220 ? report_bug+0xff/0x140 ? early_fixup_exception+0x5d/0xb0 ? early_idt_handler_common+0x2f/0x3a ? __early_ioremap+0xef/0x220 ? efi_mokvar_table_init+0xce/0x1d0 ? setup_arch+0x864/0xc10 ? start_kernel+0x6b/0xa10 ? x86_64_start_reservations+0x24/0x30 ? x86_64_start_kernel+0xed/0xf0 ? common_startup_64+0x13e/0x141 ---[ end trace 0000000000000000 ]--- mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.Mapping the entire structure isn't actually necessary, as we don't everneed more than one entry header mapped at once.Changes efi_mokvar_table_init() to only map each entry header, not theentire table, when determining the table size. Since we're not mappingany data past the variable name, it also changes the code to enforcethat each variable name is NUL terminated, rather than attempting toverify it in place.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: bsg: Fix crash when arpmb command failsIf the device doesn't support arpmb we'll crash due to copying user data inbsg_transport_sg_io_fn().In the case where ufs_bsg_exec_advanced_rpmb_req() returns an error, do notset the job's reply_len.Memory crash backtrace:3,1290,531166405,-;ufshcd 0000:00:12.5: ARPMB OP failed: error code -224,1308,531166555,-;Call Trace:4,1309,531166559,-; 4,1310,531166565,-; ? show_regs+0x6d/0x804,1311,531166575,-; ? die+0x37/0xa04,1312,531166583,-; ? do_trap+0xd4/0xf04,1313,531166593,-; ? do_error_trap+0x71/0xb04,1314,531166601,-; ? usercopy_abort+0x6c/0x804,1315,531166610,-; ? exc_invalid_op+0x52/0x804,1316,531166622,-; ? usercopy_abort+0x6c/0x804,1317,531166630,-; ? asm_exc_invalid_op+0x1b/0x204,1318,531166643,-; ? usercopy_abort+0x6c/0x804,1319,531166652,-; __check_heap_object+0xe3/0x1204,1320,531166661,-; check_heap_object+0x185/0x1d04,1321,531166670,-; __check_object_size.part.0+0x72/0x1504,1322,531166679,-; __check_object_size+0x23/0x304,1323,531166688,-; bsg_transport_sg_io_fn+0x314/0x3b0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm-integrity: Avoid divide by zero in table status in Inline modeIn Inline mode, the journal is unused, and journal_sectors is zero.Calculating the journal watermark requires dividing by journal_sectors,which should be done only if the journal is configured.Otherwise, a simple table query (dmsetup table) can cause OOPS.This bug did not show on some systems, perhaps only due tocompiler optimization.On my 32-bit testing machine, this reliably crashes with the following: : Oops: divide error: 0000 [#1] PREEMPT SMP : CPU: 0 UID: 0 PID: 2450 Comm: dmsetup Not tainted 6.14.0-rc2+ #959 : EIP: dm_integrity_status+0x2f8/0xab0 [dm_integrity] ...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: always handle address removal under msk socket lockSyzkaller reported a lockdep splat in the PM control path: WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Modules linked in: CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline] RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline] RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283 RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408 RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000 R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0 R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00 FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59 mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486 mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline] mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:733 ____sys_sendmsg+0x53a/0x860 net/socket.c:2573 ___sys_sendmsg net/socket.c:2627 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2659 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7e9998cde9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9 RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007 RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088Indeed the PM can try to send a RM_ADDR over a msk without acquiringfirst the msk socket lock.The bugged code-path comes from an early optimization: when thereare no subflows, the PM should (usually) not send RM_ADDRnotifications.The above statement is incorrect, as without locks another processcould concur---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Fix suspicious RCU usageCommit ("iommu/vt-d: Allocate DMAR fault interruptslocally") moved the call to enable_drhd_fault_handling() to a codepath that does not hold any lock while traversing the drhd list. Fixit by ensuring the dmar_global_lock lock is held when traversing thedrhd list.Without this fix, the following warning is triggered: ============================= WARNING: suspicious RCU usage 6.14.0-rc3 #55 Not tainted ----------------------------- drivers/iommu/intel/dmar.c:2046 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1 2 locks held by cpuhp/1/23: #0: ffffffff84a67c50 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0 #1: ffffffff84a6a380 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0 stack backtrace: CPU: 1 UID: 0 PID: 23 Comm: cpuhp/1 Not tainted 6.14.0-rc3 #55 Call Trace: dump_stack_lvl+0xb7/0xd0 lockdep_rcu_suspicious+0x159/0x1f0 ? __pfx_enable_drhd_fault_handling+0x10/0x10 enable_drhd_fault_handling+0x151/0x180 cpuhp_invoke_callback+0x1df/0x990 cpuhp_thread_fun+0x1ea/0x2c0 smpboot_thread_fn+0x1f5/0x2e0 ? __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x12a/0x2d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4a/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Holding the lock in enable_drhd_fault_handling() triggers a lockdep splatabout a possible deadlock between dmar_global_lock and cpu_hotplug_lock.This is avoided by not holding dmar_global_lock when callingiommu_device_register(), which initiates the device probe process.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: gl620a: fix endpoint checking in genelink_bind()Syzbot reports [1] a warning in usb_submit_urb() triggered byinconsistencies between expected and actually present endpointsin gl620a driver. Since genelink_bind() does not properlyverify whether specified eps are in fact provided by the device,in this case, an artificially manufactured one, one may get amismatch.Fix the issue by resorting to a usbnet utility functionusbnet_get_endpoints(), usually reserved for this very problem.Check for endpoints and return early before proceeding further ifany are missing.[1] Syzbot report:usb 5-1: Manufacturer: syzusb 5-1: SerialNumber: syzusb 5-1: config 0 descriptor??gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ...------------[ cut here ]------------usb 5-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503Modules linked in:CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Workqueue: mld mld_ifc_workRIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503...Call Trace: usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:3827 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_resolve_output net/core/neighbour.c:1514 [inline] neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494 neigh_output include/net/neighbour.h:539 [inline] ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 mld_send_cr net/ipv6/mcast.c:2120 [inline] mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: npcm: disable interrupt enable bit before devm_request_irqThe customer reports that there is a soft lockup issue related tothe i2c driver. After checking, the i2c module was doing a tx transferand the bmc machine reboots in the middle of the i2c transaction, the i2cmodule keeps the status without being reset.Due to such an i2c module status, the i2c irq handler keeps gettingtriggered since the i2c irq handler is registered in the kernel bootingprocess after the bmc machine is doing a warm rebooting.The continuous triggering is stopped by the soft lockup watchdog timer.Disable the interrupt enable bit in the i2c module before callingdevm_request_irq to fix this issue since the i2c relative status bitis read-only.Here is the soft lockup log.[ 28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1][ 28.183351] Modules linked in:[ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1[ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 28.208128] pc : __do_softirq+0xb0/0x368[ 28.212055] lr : __do_softirq+0x70/0x368[ 28.215972] sp : ffffff8035ebca00[ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780[ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0[ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b[ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff[ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000[ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2[ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250[ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434[ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198[ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40[ 28.290611] Call trace:[ 28.293052] __do_softirq+0xb0/0x368[ 28.296625] __irq_exit_rcu+0xe0/0x100[ 28.300374] irq_exit+0x14/0x20[ 28.303513] handle_domain_irq+0x68/0x90[ 28.307440] gic_handle_irq+0x78/0xb0[ 28.311098] call_on_irq_stack+0x20/0x38[ 28.315019] do_interrupt_handler+0x54/0x5c[ 28.319199] el1_interrupt+0x2c/0x4c[ 28.322777] el1h_64_irq_handler+0x14/0x20[ 28.326872] el1h_64_irq+0x74/0x78[ 28.330269] __setup_irq+0x454/0x780[ 28.333841] request_threaded_irq+0xd0/0x1b4[ 28.338107] devm_request_threaded_irq+0x84/0x100[ 28.342809] npcm_i2c_probe_bus+0x188/0x3d0[ 28.346990] platform_probe+0x6c/0xc4[ 28.350653] really_probe+0xcc/0x45c[ 28.354227] __driver_probe_device+0x8c/0x160[ 28.358578] driver_probe_device+0x44/0xe0[ 28.362670] __driver_attach+0x124/0x1d0[ 28.366589] bus_for_each_dev+0x7c/0xe0[ 28.370426] driver_attach+0x28/0x30[ 28.373997] bus_add_driver+0x124/0x240[ 28.377830] driver_register+0x7c/0x124[ 28.381662] __platform_driver_register+0x2c/0x34[ 28.386362] npcm_i2c_init+0x3c/0x5c[ 28.389937] do_one_initcall+0x74/0x230[ 28.393768] kernel_init_freeable+0x24c/0x2b4[ 28.398126] kernel_init+0x28/0x130[ 28.401614] ret_from_fork+0x10/0x20[ 28.405189] Kernel panic - not syncing: softlockup: hung tasks[ 28.411011] SMP: stopping secondary CPUs[ 28.414933] Kernel Offset: disabled[ 28.418412] CPU features: 0x00000000,00000802[ 28.427644] Rebooting in 20 seconds..
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix use-after-free on inode when scanning root during em shrinkingAt btrfs_scan_root() we are accessing the inode's root (and fs_info) in acall to btrfs_fs_closing() after we have scheduled the inode for a delayediput, and that can result in a use-after-free on the inode in case thecleaner kthread does the iput before we dereference the inode in the callto btrfs_fs_closing().Fix this by using the fs_info stored already in a local variable insteadof doing inode->root->fs_info.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/userptr: fix EFAULT handlingCurrently we treat EFAULT from hmm_range_fault() as a non-fatal errorwhen called from xe_vm_userptr_pin() with the idea that we want to avoidkilling the entire vm and chucking an error, under the assumption thatthe user just did an unmap or something, and has no intention ofactually touching that memory from the GPU. At this point we havealready zapped the PTEs so any access should generate a page fault, andif the pin fails there also it will then become fatal.However it looks like it's possible for the userptr vma to still be onthe rebind list in preempt_rebind_work_func(), if we had to retry thepin again due to something happening in the caller before we did therebind step, but in the meantime needing to re-validate the userptr andthis time hitting the EFAULT.This explains an internal user report of hitting:[ 191.738349] WARNING: CPU: 1 PID: 157 at drivers/gpu/drm/xe/xe_res_cursor.h:158 xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe][ 191.738551] Workqueue: xe-ordered-wq preempt_rebind_work_func [xe][ 191.738616] RIP: 0010:xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe][ 191.738690] Call Trace:[ 191.738692] [ 191.738694] ? show_regs+0x69/0x80[ 191.738698] ? __warn+0x93/0x1a0[ 191.738703] ? xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe][ 191.738759] ? report_bug+0x18f/0x1a0[ 191.738764] ? handle_bug+0x63/0xa0[ 191.738767] ? exc_invalid_op+0x19/0x70[ 191.738770] ? asm_exc_invalid_op+0x1b/0x20[ 191.738777] ? xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe][ 191.738834] ? ret_from_fork_asm+0x1a/0x30[ 191.738849] bind_op_prepare+0x105/0x7b0 [xe][ 191.738906] ? dma_resv_reserve_fences+0x301/0x380[ 191.738912] xe_pt_update_ops_prepare+0x28c/0x4b0 [xe][ 191.738966] ? kmemleak_alloc+0x4b/0x80[ 191.738973] ops_execute+0x188/0x9d0 [xe][ 191.739036] xe_vm_rebind+0x4ce/0x5a0 [xe][ 191.739098] ? trace_hardirqs_on+0x4d/0x60[ 191.739112] preempt_rebind_work_func+0x76f/0xd00 [xe]Followed by NPD, when running some workload, since the sg was neveractually populated but the vma is still marked for rebind when it shouldbe skipped for this special EFAULT case. This is confirmed to fix theuser report.v2 (MattB): - Move earlier.v3 (MattB): - Update the commit message to make it clear that this indeed fixes the issue.(cherry picked from commit 6b93cb98910c826c2e2004942f8b060311e43618)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uprobes: Reject the shared zeropage in uprobe_write_opcode()We triggered the following crash in syzkaller tests: BUG: Bad page state in process syz.7.38 pfn:1eff3 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3 flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff) raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: dump_stack_lvl+0x32/0x50 bad_page+0x69/0xf0 free_unref_page_prepare+0x401/0x500 free_unref_page+0x6d/0x1b0 uprobe_write_opcode+0x460/0x8e0 install_breakpoint.part.0+0x51/0x80 register_for_each_vma+0x1d9/0x2b0 __uprobe_register+0x245/0x300 bpf_uprobe_multi_link_attach+0x29b/0x4f0 link_create+0x1e2/0x280 __sys_bpf+0x75f/0xac0 __x64_sys_bpf+0x1a/0x30 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2 BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1The following syzkaller test case can be used to reproduce: r2 = creat(&(0x7f0000000000)='./file0\x00', 0x8) write$nbd(r2, &(0x7f0000000580)=ANY=[], 0x10) r4 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x42, 0x0) mmap$IORING_OFF_SQ_RING(&(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0) r5 = userfaultfd(0x80801) ioctl$UFFDIO_API(r5, 0xc018aa3f, &(0x7f0000000040)={0xaa, 0x20}) r6 = userfaultfd(0x80801) ioctl$UFFDIO_API(r6, 0xc018aa3f, &(0x7f0000000140)) ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, &(0x7f0000000100)={{&(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2}) ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, &(0x7f0000000000)={{&(0x7f0000ffd000/0x1000)=nil, 0x1000}}) r7 = bpf$PROG_LOAD(0x5, &(0x7f0000000140)={0x2, 0x3, &(0x7f0000000200)=ANY=[@ANYBLOB="1800000000120000000000000000000095"], &(0x7f0000000000)='GPL\x00', 0x7, 0x0, 0x0, 0x0, 0x0, '\x00', 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94) bpf$BPF_LINK_CREATE_XDP(0x1c, &(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={&(0x7f0000000080)='./file0\x00', &(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)The cause is that zero pfn is set to the PTE without increasing the RSScount in mfill_atomic_pte_zeropage() and the refcount of zero folio doesnot increase accordingly. Then, the operation on the same pfn is performedin uprobe_write_opcode()->__replace_page() to unconditional decrease theRSS count and old_folio's refcount.Therefore, two bugs are introduced: 1. The RSS count is incorrect, when process exit, the check_mm() report error "Bad rss-count". 2. The reserved folio (zero folio) is freed when folio->refcount is zero, then free_pages_prepare->free_page_is_bad() report error "Bad page state".There is more, the following warning could also theoretically be triggered: __replace_page() -> ... -> folio_remove_rmap_pte() -> VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)Considering that uprobe hit on the zero folio is a very rare case, justreject zero old folio immediately after get_user_page_vma_remote().[ mingo: Cleaned up the changelog ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix vport QoS cleanup on errorWhen enabling vport QoS fails, the scheduling node was never freed,causing a leak.Add the missing free and reset the vport scheduling node pointer toNULL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Fix deinitializing VF in error pathIf ice_ena_vfs() fails after calling ice_create_vf_entries(), it freesall VFs without removing them from snapshot PF-VF mailbox list, leadingto list corruption.Reproducer: devlink dev eswitch set $PF1_PCI mode switchdev ip l s $PF1 up ip l s $PF1 promisc on sleep 1 echo 1 > /sys/class/net/$PF1/device/sriov_numvfs sleep 1 echo 1 > /sys/class/net/$PF1/device/sriov_numvfsTrace (minimized): list_add corruption. next->prev should be prev (ffff8882e241c6f0), but was 0000000000000000. (next=ffff888455da1330). kernel BUG at lib/list_debug.c:29! RIP: 0010:__list_add_valid_or_report+0xa6/0x100 ice_mbx_init_vf_info+0xa7/0x180 [ice] ice_initialize_vf_entry+0x1fa/0x250 [ice] ice_sriov_configure+0x8d7/0x1520 [ice] ? __percpu_ref_switch_mode+0x1b1/0x5d0 ? __pfx_ice_sriov_configure+0x10/0x10 [ice]Sometimes a KASAN report can be seen instead with a similar stack trace: BUG: KASAN: use-after-free in __list_add_valid_or_report+0xf1/0x100VFs are added to this list in ice_mbx_init_vf_info(), but only removedin ice_free_vfs(). Move the removing to ice_free_vf_entries(), which isalso being called in other places where VFs are being removed (includingice_free_vfs() itself).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: better track kernel sockets lifetimeWhile kernel sockets are dismantled during pernet_operations->exit(),their freeing can be delayed by any tx packets still held in qdiscor device queues, due to skb_set_owner_w() prior calls.This then trigger the following warning from ref_tracker_dir_exit() [1]To fix this, make sure that kernel sockets own a reference on net->passive.Add sk_net_refcnt_upgrade() helper, used whenever a kernel socketis converted to a refcounted one.[1][ 136.263918][ T35] ref_tracker: net notrefcnt@ffff8880638f01e0 has 1/2 users at[ 136.263918][ T35] sk_alloc+0x2b3/0x370[ 136.263918][ T35] inet6_create+0x6ce/0x10f0[ 136.263918][ T35] __sock_create+0x4c0/0xa30[ 136.263918][ T35] inet_ctl_sock_create+0xc2/0x250[ 136.263918][ T35] igmp6_net_init+0x39/0x390[ 136.263918][ T35] ops_init+0x31e/0x590[ 136.263918][ T35] setup_net+0x287/0x9e0[ 136.263918][ T35] copy_net_ns+0x33f/0x570[ 136.263918][ T35] create_new_namespaces+0x425/0x7b0[ 136.263918][ T35] unshare_nsproxy_namespaces+0x124/0x180[ 136.263918][ T35] ksys_unshare+0x57d/0xa70[ 136.263918][ T35] __x64_sys_unshare+0x38/0x40[ 136.263918][ T35] do_syscall_64+0xf3/0x230[ 136.263918][ T35] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 136.263918][ T35][ 136.343488][ T35] ref_tracker: net notrefcnt@ffff8880638f01e0 has 1/2 users at[ 136.343488][ T35] sk_alloc+0x2b3/0x370[ 136.343488][ T35] inet6_create+0x6ce/0x10f0[ 136.343488][ T35] __sock_create+0x4c0/0xa30[ 136.343488][ T35] inet_ctl_sock_create+0xc2/0x250[ 136.343488][ T35] ndisc_net_init+0xa7/0x2b0[ 136.343488][ T35] ops_init+0x31e/0x590[ 136.343488][ T35] setup_net+0x287/0x9e0[ 136.343488][ T35] copy_net_ns+0x33f/0x570[ 136.343488][ T35] create_new_namespaces+0x425/0x7b0[ 136.343488][ T35] unshare_nsproxy_namespaces+0x124/0x180[ 136.343488][ T35] ksys_unshare+0x57d/0xa70[ 136.343488][ T35] __x64_sys_unshare+0x38/0x40[ 136.343488][ T35] do_syscall_64+0xf3/0x230[ 136.343488][ T35] entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/bnxt_re: Fix the page details for the srq created by kernel consumersWhile using nvme target with use_srq on, below kernel panic is noticed.[ 549.698111] bnxt_en 0000:41:00.0 enp65s0np0: FEC autoneg off encoding: Clause 91 RS(544,514)[ 566.393619] Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI..[ 566.393799] [ 566.393807] ? __die_body+0x1a/0x60[ 566.393823] ? die+0x38/0x60[ 566.393835] ? do_trap+0xe4/0x110[ 566.393847] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393867] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393881] ? do_error_trap+0x7c/0x120[ 566.393890] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393911] ? exc_divide_error+0x34/0x50[ 566.393923] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393939] ? asm_exc_divide_error+0x16/0x20[ 566.393966] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393997] bnxt_qplib_create_srq+0xc9/0x340 [bnxt_re][ 566.394040] bnxt_re_create_srq+0x335/0x3b0 [bnxt_re][ 566.394057] ? srso_return_thunk+0x5/0x5f[ 566.394068] ? __init_swait_queue_head+0x4a/0x60[ 566.394090] ib_create_srq_user+0xa7/0x150 [ib_core][ 566.394147] nvmet_rdma_queue_connect+0x7d0/0xbe0 [nvmet_rdma][ 566.394174] ? lock_release+0x22c/0x3f0[ 566.394187] ? srso_return_thunk+0x5/0x5fPage size and shift info is set only for the user space SRQs.Set page size and page shift for kernel space SRQs also.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix implicit ODP hang on parent deregistrationFix the destroy_unused_implicit_child_mr() to prevent hanging duringparent deregistration as of below [1].Upon entering destroy_unused_implicit_child_mr(), the reference countfor the implicit MR parent is incremented using:refcount_inc_not_zero().A corresponding decrement must be performed iffree_implicit_child_mr_work() is not called.The code has been updated to properly manage the reference count thatwas incremented.[1]INFO: task python3:2157 blocked for more than 120 seconds.Not tainted 6.12.0-rc7+ #1633"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:python3 state:D stack:0 pid:2157 tgid:2157 ppid:1685 flags:0x00000000Call Trace:__schedule+0x420/0xd30schedule+0x47/0x130__mlx5_ib_dereg_mr+0x379/0x5d0 [mlx5_ib]? __pfx_autoremove_wake_function+0x10/0x10ib_dereg_mr_user+0x5f/0x120 [ib_core]? lock_release+0xc6/0x280destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs]uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs]uobj_destroy+0x3f/0x70 [ib_uverbs]ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs]? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs]? lock_acquire+0xc1/0x2f0? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]? ib_uverbs_ioctl+0x116/0x170 [ib_uverbs]? lock_release+0xc6/0x280ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs]? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs] __x64_sys_ioctl+0x1b0/0xa70? kmem_cache_free+0x221/0x400do_syscall_64+0x6b/0x140entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7f20f21f017bRSP: 002b:00007ffcfc4a77c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007ffcfc4a78d8 RCX: 00007f20f21f017bRDX: 00007ffcfc4a78c0 RSI: 00000000c0181b01 RDI: 0000000000000003RBP: 00007ffcfc4a78a0 R08: 000056147d125190 R09: 00007f20f1f14c60R10: 0000000000000001 R11: 0000000000000246 R12: 00007ffcfc4a7890R13: 000000000000001c R14: 000056147d100fc0 R15: 00007f20e365c9d0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_upThe issue was caused by dput(upper) being called beforeovl_dentry_update_reval(), while upper->d_flags was stillaccessed in ovl_dentry_remote().Move dput(upper) after its last use to prevent use-after-free.BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline]BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 ovl_dentry_remote fs/overlayfs/util.c:162 [inline] ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 ovl_link_up fs/overlayfs/copy_up.c:610 [inline] ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170 ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223 ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136 vfs_rename+0xf84/0x20a0 fs/namei.c:4893...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix a WARN during dereg_mr for DM typeMemory regions (MR) of type DM (device memory) do not have an associatedumem.In the __mlx5_ib_dereg_mr() -> mlx5_free_priv_descs() flow, the codeincorrectly takes the wrong branch, attempting to calldma_unmap_single() on a DMA address that is not mapped.This results in a WARN [1], as shown below.The issue is resolved by properly accounting for the DM type andensuring the correct branch is selected in mlx5_free_priv_descs().[1]WARNING: CPU: 12 PID: 1346 at drivers/iommu/dma-iommu.c:1230 iommu_dma_unmap_page+0x79/0x90Modules linked in: ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry ovelay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_coreCPU: 12 UID: 0 PID: 1346 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1631Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:iommu_dma_unmap_page+0x79/0x90Code: 2b 49 3b 29 72 26 49 3b 69 08 73 20 4d 89 f0 44 89 e9 4c 89 e2 48 89 ee 48 89 df 5b 5d 41 5c 41 5d 41 5e 41 5f e9 07 b8 88 ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 66 0f 1f 44 00RSP: 0018:ffffc90001913a10 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff88810194b0a8 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001RBP: ffff88810194b0a8 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000FS: 00007f537abdd740(0000) GS:ffff88885fb00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f537aeb8000 CR3: 000000010c248001 CR4: 0000000000372eb0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:? __warn+0x84/0x190? iommu_dma_unmap_page+0x79/0x90? report_bug+0xf8/0x1c0? handle_bug+0x55/0x90? exc_invalid_op+0x13/0x60? asm_exc_invalid_op+0x16/0x20? iommu_dma_unmap_page+0x79/0x90dma_unmap_page_attrs+0xe6/0x290mlx5_free_priv_descs+0xb0/0xe0 [mlx5_ib]__mlx5_ib_dereg_mr+0x37e/0x520 [mlx5_ib]? _raw_spin_unlock_irq+0x24/0x40? wait_for_completion+0xfe/0x130? rdma_restrack_put+0x63/0xe0 [ib_core]ib_dereg_mr_user+0x5f/0x120 [ib_core]? lock_release+0xc6/0x280destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs]uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs]uobj_destroy+0x3f/0x70 [ib_uverbs]ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs]? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs]? lock_acquire+0xc1/0x2f0? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]? ib_uverbs_ioctl+0x116/0x170 [ib_uverbs]? lock_release+0xc6/0x280ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs]? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]__x64_sys_ioctl+0x1b0/0xa70do_syscall_64+0x6b/0x140entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7f537adaf17bCode: 0f 1e fa 48 8b 05 1d ad 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ed ac 0c 00 f7 d8 64 89 01 48RSP: 002b:00007ffff218f0b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007ffff218f1d8 RCX: 00007f537adaf17bRDX: 00007ffff218f1c0 RSI: 00000000c0181b01 RDI: 0000000000000003RBP: 00007ffff218f1a0 R08: 00007f537aa8d010 R09: 0000561ee2e4f270R10: 00007f537aace3a8 R11: 0000000000000246 R12: 00007ffff218f190R13: 000000000000001c R14: 0000561ee2e4d7c0 R15: 00007ffff218f450
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Add RCU read lock protection to perf_iterate_ctx()The perf_iterate_ctx() function performs RCU list traversal butcurrently lacks RCU read lock protection. This causes lockdep warningswhen running perf probe with unshare(1) under CONFIG_PROVE_RCU_LIST=y: WARNING: suspicious RCU usage kernel/events/core.c:8168 RCU-list traversed in non-reader section!! Call Trace: lockdep_rcu_suspicious ? perf_event_addr_filters_apply perf_iterate_ctx perf_event_exec begin_new_exec ? load_elf_phdrs load_elf_binary ? lock_acquire ? find_held_lock ? bprm_execve bprm_execve do_execveat_common.isra.0 __x64_sys_execve do_syscall_64 entry_SYSCALL_64_after_hwframeThis protection was previously present but was removed in commitbd2756811766 ("perf: Rewrite core context handling"). Add back thenecessary rcu_read_lock()/rcu_read_unlock() pair aroundperf_iterate_ctx() call in perf_event_exec().[ mingo: Use scoped_guard() as suggested by Peter ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix checksums set in idpf_rx_rsc()idpf_rx_rsc() uses skb_transport_offset(skb) while the transport headeris not set yet.This triggers the following warning for CONFIG_DEBUG_NET=y builds.DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb))[ 69.261620] WARNING: CPU: 7 PID: 0 at ./include/linux/skbuff.h:3020 idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261629] Modules linked in: vfat fat dummy bridge intel_uncore_frequency_tpmi intel_uncore_frequency_common intel_vsec_tpmi idpf intel_vsec cdc_ncm cdc_eem cdc_ether usbnet mii xhci_pci xhci_hcd ehci_pci ehci_hcd libeth[ 69.261644] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Tainted: G S W 6.14.0-smp-DEV #1697[ 69.261648] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN[ 69.261650] RIP: 0010:idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261677] ? __warn (kernel/panic.c:242 kernel/panic.c:748)[ 69.261682] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261687] ? report_bug (lib/bug.c:?)[ 69.261690] ? handle_bug (arch/x86/kernel/traps.c:285)[ 69.261694] ? exc_invalid_op (arch/x86/kernel/traps.c:309)[ 69.261697] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)[ 69.261700] ? __pfx_idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:4011) idpf[ 69.261704] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261708] ? idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:3072) idpf[ 69.261712] __napi_poll (net/core/dev.c:7194)[ 69.261716] net_rx_action (net/core/dev.c:7265)[ 69.261718] ? __qdisc_run (net/sched/sch_generic.c:293)[ 69.261721] ? sched_clock (arch/x86/include/asm/preempt.h:84 arch/x86/kernel/tsc.c:288)[ 69.261726] handle_softirqs (kernel/softirq.c:561)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: ensure network headers are in skb linear partsyzbot found that ipvlan_process_v6_outbound() was assumingthe IPv6 network header isis present in skb->head [1]Add the needed pskb_network_may_pull() calls for bothIPv4 and IPv6 handlers.[1]BUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 ipv6_addr_type include/net/ipv6.h:555 [inline] ip6_route_output_flags_noref net/ipv6/route.c:2616 [inline] ip6_route_output_flags+0x51/0x720 net/ipv6/route.c:2651 ip6_route_output include/net/ip6_route.h:93 [inline] ipvlan_route_v6_outbound+0x24e/0x520 drivers/net/ipvlan/ipvlan_core.c:476 ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:491 [inline] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:541 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:605 [inline] ipvlan_queue_xmit+0xd72/0x1780 drivers/net/ipvlan/ipvlan_core.c:671 ipvlan_start_xmit+0x5b/0x210 drivers/net/ipvlan/ipvlan_main.c:223 __netdev_start_xmit include/linux/netdevice.h:5150 [inline] netdev_start_xmit include/linux/netdevice.h:5159 [inline] xmit_one net/core/dev.c:3735 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3751 sch_direct_xmit+0x399/0xd40 net/sched/sch_generic.c:343 qdisc_restart net/sched/sch_generic.c:408 [inline] __qdisc_run+0x14da/0x35d0 net/sched/sch_generic.c:416 qdisc_run+0x141/0x4d0 include/net/pkt_sched.h:127 net_tx_action+0x78b/0x940 net/core/dev.c:5484 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4611 dev_queue_xmit include/linux/netdevice.h:3311 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3132 [inline] packet_sendmsg+0x93e0/0xa7e0 net/packet/af_packet.c:3164 sock_sendmsg_nosec net/socket.c:718 [inline]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix the recovery flow of the UMR QPThis patch addresses an issue in the recovery flow of the UMR QP,ensuring tasks do not get stuck, as highlighted by the call trace [1].During recovery, before transitioning the QP to the RESET state, thesoftware must wait for all outstanding WRs to complete.Failing to do so can cause the firmware to skip sending some flushedCQEs with errors and simply discard them upon the RESET, as per the IBspecification.This race condition can result in lost CQEs and tasks becoming stuck.To resolve this, the patch sends a final WR which serves only as abarrier before moving the QP state to RESET.Once a CQE is received for that final WR, it guarantees that nooutstanding WRs remain, making it safe to transition the QP to RESET andsubsequently back to RTS, restoring proper functionality.Note:For the barrier WR, we simply reuse the failed and ready WR.Since the QP is in an error state, it will only receiveIB_WC_WR_FLUSH_ERR. However, as it serves only as a barrier we don'tcare about its status.[1]INFO: task rdma_resource_l:1922 blocked for more than 120 seconds.Tainted: G W 6.12.0-rc7+ #1626"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:rdma_resource_l state:D stack:0 pid:1922 tgid:1922 ppid:1369 flags:0x00004004Call Trace:__schedule+0x420/0xd30schedule+0x47/0x130schedule_timeout+0x280/0x300? mark_held_locks+0x48/0x80? lockdep_hardirqs_on_prepare+0xe5/0x1a0wait_for_completion+0x75/0x130mlx5r_umr_post_send_wait+0x3c2/0x5b0 [mlx5_ib]? __pfx_mlx5r_umr_done+0x10/0x10 [mlx5_ib]mlx5r_umr_revoke_mr+0x93/0xc0 [mlx5_ib]__mlx5_ib_dereg_mr+0x299/0x520 [mlx5_ib]? _raw_spin_unlock_irq+0x24/0x40? wait_for_completion+0xfe/0x130? rdma_restrack_put+0x63/0xe0 [ib_core]ib_dereg_mr_user+0x5f/0x120 [ib_core]? lock_release+0xc6/0x280destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs]uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs]uobj_destroy+0x3f/0x70 [ib_uverbs]ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs]? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs]? __lock_acquire+0x64e/0x2080? mark_held_locks+0x48/0x80? find_held_lock+0x2d/0xa0? lock_acquire+0xc1/0x2f0? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]? __fget_files+0xc3/0x1b0ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs]? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]__x64_sys_ioctl+0x1b0/0xa70do_syscall_64+0x6b/0x140entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7f99c918b17bRSP: 002b:00007ffc766d0468 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007ffc766d0578 RCX: 00007f99c918b17bRDX: 00007ffc766d0560 RSI: 00000000c0181b01 RDI: 0000000000000003RBP: 00007ffc766d0540 R08: 00007f99c8f99010 R09: 000000000000bd7eR10: 00007f99c94c1c70 R11: 0000000000000246 R12: 00007ffc766d0530R13: 000000000000001c R14: 0000000040246a80 R15: 0000000000000000
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:keys: Fix UAF in key_put()Once a key's reference count has been reduced to 0, the garbage collectorthread may destroy it at any time and so key_put() is not allowed to touchthe key after that point. The most key_put() is normally allowed to do isto touch key_gc_work as that's a static global variable.However, in an effort to speed up the reclamation of quota, this is nowdone in key_put() once the key's usage is reduced to 0 - but now the codeis looking at the key after the deadline, which is forbidden.Fix this by using a flag to indicate that a key can be gc'd now rather thanlooking at the key's refcount in the garbage collector.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: VFs do not support HWTSTAMP_TX_ONESTEP_SYNCActually ENETC VFs do not support HWTSTAMP_TX_ONESTEP_SYNC because onlyENETC PF can access PMa_SINGLE_STEP registers. And there will be a crashif VFs are used to test one-step timestamp, the crash log as follows.[ 129.110909] Unable to handle kernel paging request at virtual address 00000000000080c0[ 129.287769] Call trace:[ 129.290219] enetc_port_mac_wr+0x30/0xec (P)[ 129.294504] enetc_start_xmit+0xda4/0xe74[ 129.298525] enetc_xmit+0x70/0xec[ 129.301848] dev_hard_start_xmit+0x98/0x118
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Avoid potential division by zero in function_stat_show()Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64}produce zero and skip stddev computation in that case.For now don't care about rec->counter * rec->counter overflow becauserec->time * rec->time overflow will likely happen earlier.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix bad hist from corrupting named_triggers listThe following commands causes a crash: ~# cd /sys/kernel/tracing/events/rcu/rcu_callback ~# echo 'hist:name=bad:keys=common_pid:onmax(bogus).save(common_pid)' > trigger bash: echo: write error: Invalid argument ~# echo 'hist:name=bad:keys=common_pid' > triggerBecause the following occurs:event_trigger_write() { trigger_process_regex() { event_hist_trigger_parse() { data = event_trigger_alloc(..); event_trigger_register(.., data) { cmd_ops->reg(.., data, ..) [hist_register_trigger()] { data->ops->init() [event_hist_trigger_init()] { save_named_trigger(name, data) { list_add(&data->named_list, &named_triggers); } } } } ret = create_actions(); (return -EINVAL) if (ret) goto out_unreg;[..] ret = hist_trigger_enable(data, ...) { list_add_tail_rcu(&data->list, &file->triggers); <<<---- SKIPPED!!! (this is important!)[..] out_unreg: event_hist_unregister(.., data) { cmd_ops->unreg(.., data, ..) [hist_unregister_trigger()] { list_for_each_entry(iter, &file->triggers, list) { if (!hist_trigger_match(data, iter, named_data, false)) <- never matches continue; [..] test = iter; } if (test && test->ops->free) <<<-- test is NULL test->ops->free(test) [event_hist_trigger_free()] { [..] if (data->name) del_named_trigger(data) { list_del(&data->named_list); <<<<-- NEVER gets removed! } } } } [..] kfree(data); <<<-- frees item but it is still on listThe next time a hist with name is registered, it causes an u-a-f bug andthe kernel can crash.Move the code around such that if event_trigger_register() succeeds, thenext thing called is hist_trigger_enable() which adds it to the list.A bunch of actions is called if get_named_trigger_data() returns false.But that doesn't need to be called after event_trigger_register(), so itcan be moved up, allowing event_trigger_register() to be called justbefore hist_trigger_enable() keeping them together and allowing thefile->triggers to be properly populated.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:caif_virtio: fix wrong pointer check in cfv_probe()del_vqs() frees virtqueues, therefore cfv->vq_tx pointer should be checkedfor NULL before calling it, not cfv->vdev. Also the current implementationis redundant because the pointer cfv->vdev is dereferenced before it ischecked for NULL.Fix this by checking cfv->vq_tx for NULL instead of cfv->vdev beforecalling del_vqs().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: limit printed string from FW fileThere's no guarantee here that the file is always with aNUL-termination, so reading the string may read beyond theend of the TLV. If that's the last TLV in the file, it canperhaps even read beyond the end of the file buffer.Fix that by limiting the print format to the size of thebuffer we have.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: nl80211: reject cooked mode if it is set along with other flagsIt is possible to set both MONITOR_FLAG_COOK_FRAMES and MONITOR_FLAG_ACTIVEflags simultaneously on the same monitor interface from the userspace. Thiscauses a sub-interface to be created with no IEEE80211_SDATA_IN_DRIVER bitset because the monitor interface is in the cooked state and it takesprecedence over all other states. When the interface is then being deletedthe kernel calls WARN_ONCE() from check_sdata_in_driver() because of missingthat bit.Fix this by rejecting MONITOR_FLAG_COOK_FRAMES if it is set along withother flags.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: regulatory: improve invalid hints checkingSyzbot keeps reporting an issue [1] that occurs when erroneous symbolssent from userspace get through into user_alpha2[] viaregulatory_hint_user() call. Such invalid regulatory hints should berejected.While a sanity check from commit 47caf685a685 ("cfg80211: regulatory:reject invalid hints") looks to be enough to deter these very cases,there is a way to get around it due to 2 reasons.1) The way isalpha() works, symbols other than latin lower andupper letters may be used to determine a country/domain.For instance, greek letters will also be considered upper/lowerletters and for such characters isalpha() will return true as well.However, ISO-3166-1 alpha2 codes should only hold latincharacters.2) While processing a user regulatory request, betweenreg_process_hint_user() and regulatory_hint_user() there happens tobe a call to queue_regulatory_request() which modifies letters inrequest->alpha2[] with toupper(). This works fine for latin symbols,less so for weird letter characters from the second part of _ctype[].Syzbot triggers a warning in is_user_regdom_saved() by first sendingover an unexpected non-latin letter that gets malformed by toupper()into a character that ends up failing isalpha() check.Prevent this by enhancing is_an_alpha2() to ensure that incomingsymbols are latin letters and nothing else.[1] Syzbot report:------------[ cut here ]------------Unexpected user alpha2: A�WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 is_user_regdom_saved net/wireless/reg.c:440 [inline]WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_alpha2 net/wireless/reg.c:3424 [inline]WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516Modules linked in:CPU: 1 UID: 0 PID: 964 Comm: kworker/1:2 Not tainted 6.12.0-rc5-syzkaller-00044-gc1e939a21eb1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: events_power_efficient crda_timeout_workRIP: 0010:is_user_regdom_saved net/wireless/reg.c:440 [inline]RIP: 0010:restore_alpha2 net/wireless/reg.c:3424 [inline]RIP: 0010:restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516...Call Trace: crda_timeout_work+0x27/0x50 net/wireless/reg.c:542 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f2/0x390 kernel/kthread.c:389 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:slimbus: messaging: Free transaction ID in delayed interrupt scenarioIn case of interrupt delay for any reason, slim_do_transfer()returns timeout error but the transaction ID (TID) is not freed.This results into invalid memory access insideqcom_slim_ngd_rx_msgq_cb() due to invalid TID.Fix the issue by freeing the TID in slim_do_transfer() beforereturning timeout error to avoid invalid memory access.Call trace:__memcpy_fromio+0x20/0x190qcom_slim_ngd_rx_msgq_cb+0x130/0x290 [slim_qcom_ngd_ctrl]vchan_complete+0x2a0/0x4a0tasklet_action_common+0x274/0x700tasklet_action+0x28/0x3c_stext+0x188/0x620run_ksoftirqd+0x34/0x74smpboot_thread_fn+0x1d8/0x464kthread+0x178/0x238ret_from_fork+0x10/0x20Code: aa0003e8 91000429 f100044a 3940002b (3800150b)---[ end trace 0fe00bec2b975c99 ]---Kernel panic - not syncing: Oops: Fatal exception in interrupt.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: atm: cxacru: fix a flaw in existing endpoint checksSyzbot once again identified a flaw in usb endpoint checking, see [1].This time the issue stems from a commit authored by me (2eabb655a968("usb: atm: cxacru: fix endpoint checking in cxacru_bind()")).While using usb_find_common_endpoints() may usually be enough todiscard devices with wrong endpoints, in this case one needs morethan just finding and identifying the sufficient number of endpointsof correct types - one needs to check the endpoint's address as well.Since cxacru_bind() fills URBs with CXACRU_EP_CMD address in mind,switch the endpoint verification approach to usb_check_XXX_endpoints()instead to fix incomplete ep testing.[1] Syzbot report:usb 5-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 0 PID: 1378 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503...RIP: 0010:usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503...Call Trace: cxacru_cm+0x3c8/0xe50 drivers/usb/atm/cxacru.c:649 cxacru_card_status drivers/usb/atm/cxacru.c:760 [inline] cxacru_bind+0xcf9/0x1150 drivers/usb/atm/cxacru.c:1223 usbatm_usb_probe+0x314/0x1d30 drivers/usb/atm/usbatm.c:1058 cxacru_usb_probe+0x184/0x220 drivers/usb/atm/cxacru.c:1377 usb_probe_interface+0x641/0xbb0 drivers/usb/core/driver.c:396 really_probe+0x2b9/0xad0 drivers/base/dd.c:658 __driver_probe_device+0x1a2/0x390 drivers/base/dd.c:800 driver_probe_device+0x50/0x430 drivers/base/dd.c:830...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: renesas_usbhs: Flush the notify_hotplug_workWhen performing continuous unbind/bind operations on the USB driversavailable on the Renesas RZ/G2L SoC, a kernel crash with the message"Unable to handle kernel NULL pointer dereference at virtual address"may occur. This issue points to the usbhsc_notify_hotplug() function.Flush the delayed work to avoid its execution when driver resources areunavailable.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: Fix NULL pointer accessResources should be released only after all threads that utilize themhave been destroyed.This commit ensures that resources are not released prematurely by waitingfor the associated workqueue to complete before deallocating them.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/fair: Fix potential memory corruption in child_cfs_rq_on_listchild_cfs_rq_on_list attempts to convert a 'prev' pointer to a cfs_rq.This 'prev' pointer can originate from struct rq's leaf_cfs_rq_list,making the conversion invalid and potentially leading to memorycorruption. Depending on the relative positions of leaf_cfs_rq_list andthe task group (tg) pointer within the struct, this can cause a memoryfault or access garbage data.The issue arises in list_add_leaf_cfs_rq, where bothcfs_rq->leaf_cfs_rq_list and rq->leaf_cfs_rq_list are added to the sameleaf list. Also, rq->tmp_alone_branch can be set to rq->leaf_cfs_rq_list.This adds a check `if (prev == &rq->leaf_cfs_rq_list)` after the mainconditional in child_cfs_rq_on_list. This ensures that the container_ofoperation will convert a correct cfs_rq struct.This check is sufficient because only cfs_rqs on the same CPU are addedto the list, so verifying the 'prev' pointer against the current rq's listhead is enough.Fixes a potential memory corruption issue that due to current structlayout might not be manifesting as a crash but could lead to unpredictablebehavior when the layout changes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vlan: enforce underlying device typeCurrently, VLAN devices can be created on top of non-ethernet devices.Besides the fact that it doesn't make much sense, this also causes abug which leaks the address of a kernel function to usermode.When creating a VLAN device, we initialize GARP (garp_init_applicant)and MRP (mrp_init_applicant) for the underlying device.As part of the initialization process, we add the multicast address ofeach applicant to the underlying device, by calling dev_mc_add.__dev_mc_add uses dev->addr_len to determine the length of the newmulticast address.This causes an out-of-bounds read if dev->addr_len is greater than 6,since the multicast addresses provided by GARP and MRP are only 6bytes long.This behaviour can be reproduced using the following commands:ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev loip l set up dev gretestip link add link gretest name vlantest type vlan id 100Then, the following command will display the address of garp_pdu_rcv:ip maddr show | grep 01:80:c2:00:00:21Fix the bug by enforcing the type of the underlying device during VLANdevice initialization.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: make sure ptp clock is unregister and freed if hclge_ptp_get_cycle returns an errorDuring the initialization of ptp, hclge_ptp_get_cycle might return an errorand returned directly without unregister clock and free it. To avoid that,call hclge_ptp_destroy_clock to unregist and free clock ifhclge_ptp_get_cycle failed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:llc: do not use skb_get() before dev_queue_xmit()syzbot is able to crash hosts [1], using llc and devicesnot supporting IFF_TX_SKB_SHARING.In this case, e1000 driver calls eth_skb_pad(), whilethe skb is shared.Simply replace skb_get() by skb_clone() in net/llc/llc_s_ac.cNote that e1000 driver might have an issue with pktgen,because it does not clear IFF_TX_SKB_SHARING, this is anorthogonal change.We need to audit other skb_get() uses in net/llc.[1]kernel BUG at net/core/skbuff.c:2178 !Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:pskb_expand_head+0x6ce/0x1240 net/core/skbuff.c:2178Call Trace: __skb_pad+0x18a/0x610 net/core/skbuff.c:2466 __skb_put_padto include/linux/skbuff.h:3843 [inline] skb_put_padto include/linux/skbuff.h:3862 [inline] eth_skb_pad include/linux/etherdevice.h:656 [inline] e1000_xmit_frame+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000_main.c:3128 __netdev_start_xmit include/linux/netdevice.h:5151 [inline] netdev_start_xmit include/linux/netdevice.h:5160 [inline] xmit_one net/core/dev.c:3806 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3822 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:4045 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4621 dev_queue_xmit include/linux/netdevice.h:3313 [inline] llc_sap_action_send_test_c+0x268/0x320 net/llc/llc_s_ac.c:144 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x239/0x510 net/llc/llc_sap.c:209 llc_ui_sendmsg+0xd0d/0x14e0 net/llc/af_llc.c:993 sock_sendmsg_nosec net/socket.c:718 [inline]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: gso: fix ownership in __udp_gso_segmentIn __udp_gso_segment the skb destructor is removed before segmenting theskb but the socket reference is kept as-is. This is an issue if theoriginal skb is later orphaned as we can hit the following bug: kernel BUG at ./include/linux/skbuff.h:3312! (skb_orphan) RIP: 0010:ip_rcv_core+0x8b2/0xca0 Call Trace: ip_rcv+0xab/0x6e0 __netif_receive_skb_one_core+0x168/0x1b0 process_backlog+0x384/0x1100 __napi_poll.constprop.0+0xa1/0x370 net_rx_action+0x925/0xe50The above can happen following a sequence of events when usingOpenVSwitch, when an OVS_ACTION_ATTR_USERSPACE action precedes anOVS_ACTION_ATTR_OUTPUT action:1. OVS_ACTION_ATTR_USERSPACE is handled (in do_execute_actions): the skb goes through queue_gso_packets and then __udp_gso_segment, where its destructor is removed.2. The segments' data are copied and sent to userspace.3. OVS_ACTION_ATTR_OUTPUT is handled (in do_execute_actions) and the same original skb is sent to its path.4. If it later hits skb_orphan, we hit the bug.Fix this by also removing the reference to the socket in__udp_gso_segment.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu()nvme_tcp_recv_pdu() doesn't check the validity of the header length.When header digests are enabled, a target might send a packet with aninvalid header length (e.g. 255), causing nvme_tcp_verify_hdgst()to access memory outside the allocated area and cause memory corruptionsby overwriting it with the calculated digest.Fix this by rejecting packets with an unexpected header length.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()The system can experience a random crash a few minutes after the driver isremoved. This issue occurs due to improper handling of memory freeing inthe ishtp_hid_remove() function.The function currently frees the `driver_data` directly within the loopthat destroys the HID devices, which can lead to accessing freed memory.Specifically, `hid_destroy_device()` uses `driver_data` when it calls`hid_ishtp_set_feature()` to power off the sensor, so freeing`driver_data` beforehand can result in accessing invalid memory.This patch resolves the issue by storing the `driver_data` in a temporaryvariable before calling `hid_destroy_device()`, and then freeing the`driver_data` after the device is destroyed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folioCommit b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned pages tobe offlined) add page poison checks in do_migrate_range in order to makeoffline hwpoisoned page possible by introducing isolate_lru_page andtry_to_unmap for hwpoisoned page. However folio lock must be held beforecalling try_to_unmap. Add it to fix this problem.Warning will be produced if folio is not locked during unmap: ------------[ cut here ]------------ kernel BUG at ./include/linux/swapops.h:400! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41 Tainted: [W]=WARN Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0xb08/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Call trace: try_to_unmap_one+0xb08/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000) ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: fix an API misues when rio_add_net() failsrio_add_net() calls device_register() and fails when device_register()fails. Thus, put_device() should be used rather than kfree(). Add"mport->net = NULL;" to avoid a use after free issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: add check for rio_add_net() in rio_scan_alloc_net()The return value of rio_add_net() should be checked. If it fails,put_device() should be called to free the memory and give up the referenceinitialized in rio_add_net().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Add check for mgmt_alloc_skb() in mgmt_device_connected()Add check for the return value of mgmt_alloc_skb() inmgmt_device_connected() to prevent null pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Add check for mgmt_alloc_skb() in mgmt_remote_name()Add check for the return value of mgmt_alloc_skb() inmgmt_remote_name() to prevent null pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx->plane_state in resource_build_scaling_paramsNull pointer dereference issue could occur when pipe_ctx->plane_stateis null. The fix adds a check to ensure 'pipe_ctx->plane_state' is notnull before accessing. This prevents a null pointer dereference.Found by code review.(cherry picked from commit 63e6a77ccf239337baa9b1e7787cde9fa0462092)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: appleir: Fix potential NULL dereference at raw event handleSyzkaller reports a NULL pointer dereference issue in input_event().BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:68 [inline]BUG: KASAN: null-ptr-deref in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]BUG: KASAN: null-ptr-deref in is_event_supported drivers/input/input.c:67 [inline]BUG: KASAN: null-ptr-deref in input_event+0x42/0xa0 drivers/input/input.c:395Read of size 8 at addr 0000000000000028 by task syz-executor199/2949CPU: 0 UID: 0 PID: 2949 Comm: syz-executor199 Not tainted 6.13.0-rc4-syzkaller-00076-gf097a36ef88d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 kasan_report+0xd9/0x110 mm/kasan/report.c:602 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 instrument_atomic_read include/linux/instrumented.h:68 [inline] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] is_event_supported drivers/input/input.c:67 [inline] input_event+0x42/0xa0 drivers/input/input.c:395 input_report_key include/linux/input.h:439 [inline] key_down drivers/hid/hid-appleir.c:159 [inline] appleir_raw_event+0x3e5/0x5e0 drivers/hid/hid-appleir.c:232 __hid_input_report.constprop.0+0x312/0x440 drivers/hid/hid-core.c:2111 hid_ctrl+0x49f/0x550 drivers/hid/usbhid/hid-core.c:484 __usb_hcd_giveback_urb+0x389/0x6e0 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x396/0x450 drivers/usb/core/hcd.c:1734 dummy_timer+0x17f7/0x3960 drivers/usb/gadget/udc/dummy_hcd.c:1993 __run_hrtimer kernel/time/hrtimer.c:1739 [inline] __hrtimer_run_queues+0x20a/0xae0 kernel/time/hrtimer.c:1803 hrtimer_run_softirq+0x17d/0x350 kernel/time/hrtimer.c:1820 handle_softirqs+0x206/0x8d0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xfa/0x160 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0x90/0xb0 arch/x86/kernel/apic/apic.c:1049 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 __mod_timer+0x8f6/0xdc0 kernel/time/timer.c:1185 add_timer+0x62/0x90 kernel/time/timer.c:1295 schedule_timeout+0x11f/0x280 kernel/time/sleep_timeout.c:98 usbhid_wait_io+0x1c7/0x380 drivers/hid/usbhid/hid-core.c:645 usbhid_init_reports+0x19f/0x390 drivers/hid/usbhid/hid-core.c:784 hiddev_ioctl+0x1133/0x15b0 drivers/hid/usbhid/hiddev.c:794 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f This happens due to the malformed report items sent by the emulated devicewhich results in a report, that has no fields, being added to the report list.Due to this appleir_input_configured() is never called, hidinput_connect()fails which results in the HID_CLAIMED_INPUT flag is not being set. However,it does not make appleir_probe() fail and lets the event callback to becalled without the associated input device.Thus, add a check for the HID_CLAIMED_INPUT flag and leave the event hookearly if the driver didn't claim any input_dev for some reason. Moreover,some other hid drivers accessing input_dev in their event callbacks do havesimilar checks, too.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: virt: acrn: hsm: Use kzalloc to avoid info leak in pmcmd_ioctlIn the "pmcmd_ioctl" function, three memory objects allocated bykmalloc are initialized by "hcall_get_cpu_state", which are thencopied to user space. The initializer is indeed implemented in"acrn_hypercall2" (arch/x86/include/asm/acrn.h). There is a risk ofinformation leakage due to uninitialized bytes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlockThere are multiple places from where the recovery work gets scheduledasynchronously. Also, there are multiple places where the caller waitssynchronously for the recovery to be completed. One such place is duringthe PM shutdown() callback.If the device is not alive during recovery_work, it will try to reset thedevice using pci_reset_function(). This function internally will take thedevice_lock() first before resetting the device. By this time, if the lockhas already been acquired, then recovery_work will get stalled whilewaiting for the lock. And if the lock was already acquired by the callerwhich waits for the recovery_work to be completed, it will lead todeadlock.This is what happened on the X1E80100 CRD device when the device diedbefore shutdown() callback. Driver core calls the driver's shutdown()callback while holding the device_lock() leading to deadlock.And this deadlock scenario can occur on other paths as well, like duringthe PM suspend() callback, where the driver core would hold thedevice_lock() before calling driver's suspend() callback. And if therecovery_work was already started, it could lead to deadlock. This is alsoobserved on the X1E80100 CRD.So to fix both issues, use pci_try_reset_function() in recovery_work. Thisfunction first checks for the availability of the device_lock() beforetrying to reset the device. If the lock is available, it will acquire itand reset the device. Otherwise, it will return -EAGAIN. If that happens,recovery_work will fail with the error message "Recovery failed" as notmuch could be done.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mana: cleanup mana struct after debugfs_remove()When on a MANA VM hibernation is triggered, as part of hibernate_snapshot(),mana_gd_suspend() and mana_gd_resume() are called. If during thismana_gd_resume(), a failure occurs with HWC creation, mana_port_debugfspointer does not get reinitialized and ends up pointing to older,cleaned-up dentry.Further in the hibernation path, as part of power_down(), mana_gd_shutdown()is triggered. This call, unaware of the failures in resume, tries to cleanupthe already cleaned up mana_port_debugfs value and hits the following bug:[ 191.359296] mana 7870:00:00.0: Shutdown was called[ 191.359918] BUG: kernel NULL pointer dereference, address: 0000000000000098[ 191.360584] #PF: supervisor write access in kernel mode[ 191.361125] #PF: error_code(0x0002) - not-present page[ 191.361727] PGD 1080ea067 P4D 0[ 191.362172] Oops: Oops: 0002 [#1] SMP NOPTI[ 191.362606] CPU: 11 UID: 0 PID: 1674 Comm: bash Not tainted 6.14.0-rc5+ #2[ 191.363292] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024[ 191.364124] RIP: 0010:down_write+0x19/0x50[ 191.364537] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb e8 de cd ff ff 31 c0 ba 01 00 00 00 48 0f b1 13 75 16 65 48 8b 05 88 24 4c 6a 48 89 43 08 48 8b 5d[ 191.365867] RSP: 0000:ff45fbe0c1c037b8 EFLAGS: 00010246[ 191.366350] RAX: 0000000000000000 RBX: 0000000000000098 RCX: ffffff8100000000[ 191.366951] RDX: 0000000000000001 RSI: 0000000000000064 RDI: 0000000000000098[ 191.367600] RBP: ff45fbe0c1c037c0 R08: 0000000000000000 R09: 0000000000000001[ 191.368225] R10: ff45fbe0d2b01000 R11: 0000000000000008 R12: 0000000000000000[ 191.368874] R13: 000000000000000b R14: ff43dc27509d67c0 R15: 0000000000000020[ 191.369549] FS: 00007dbc5001e740(0000) GS:ff43dc663f380000(0000) knlGS:0000000000000000[ 191.370213] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 191.370830] CR2: 0000000000000098 CR3: 0000000168e8e002 CR4: 0000000000b73ef0[ 191.371557] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 191.372192] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400[ 191.372906] Call Trace:[ 191.373262] [ 191.373621] ? show_regs+0x64/0x70[ 191.374040] ? __die+0x24/0x70[ 191.374468] ? page_fault_oops+0x290/0x5b0[ 191.374875] ? do_user_addr_fault+0x448/0x800[ 191.375357] ? exc_page_fault+0x7a/0x160[ 191.375971] ? asm_exc_page_fault+0x27/0x30[ 191.376416] ? down_write+0x19/0x50[ 191.376832] ? down_write+0x12/0x50[ 191.377232] simple_recursive_removal+0x4a/0x2a0[ 191.377679] ? __pfx_remove_one+0x10/0x10[ 191.378088] debugfs_remove+0x44/0x70[ 191.378530] mana_detach+0x17c/0x4f0[ 191.378950] ? __flush_work+0x1e2/0x3b0[ 191.379362] ? __cond_resched+0x1a/0x50[ 191.379787] mana_remove+0xf2/0x1a0[ 191.380193] mana_gd_shutdown+0x3b/0x70[ 191.380642] pci_device_shutdown+0x3a/0x80[ 191.381063] device_shutdown+0x13e/0x230[ 191.381480] kernel_power_off+0x35/0x80[ 191.381890] hibernate+0x3c6/0x470[ 191.382312] state_store+0xcb/0xd0[ 191.382734] kobj_attr_store+0x12/0x30[ 191.383211] sysfs_kf_write+0x3e/0x50[ 191.383640] kernfs_fop_write_iter+0x140/0x1d0[ 191.384106] vfs_write+0x271/0x440[ 191.384521] ksys_write+0x72/0xf0[ 191.384924] __x64_sys_write+0x19/0x20[ 191.385313] x64_sys_call+0x2b0/0x20b0[ 191.385736] do_syscall_64+0x79/0x150[ 191.386146] ? __mod_memcg_lruvec_state+0xe7/0x240[ 191.386676] ? __lruvec_stat_mod_folio+0x79/0xb0[ 191.387124] ? __pfx_lru_add+0x10/0x10[ 191.387515] ? queued_spin_unlock+0x9/0x10[ 191.387937] ? do_anonymous_page+0x33c/0xa00[ 191.388374] ? __handle_mm_fault+0xcf3/0x1210[ 191.388805] ? __count_memcg_events+0xbe/0x180[ 191.389235] ? handle_mm_fault+0xae/0x300[ 19---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix integer overflow while processing acdirmax mount optionUser-provided mount parameter acdirmax of type u32 is intended to havean upper limit, but before it is validated, the value is converted fromseconds to jiffies which can lead to an integer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix integer overflow while processing acregmax mount optionUser-provided mount parameter acregmax of type u32 is intended to havean upper limit, but before it is validated, the value is converted fromseconds to jiffies which can lead to an integer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix slab-use-after-free on hdcp_work[Why]A slab-use-after-free is reported when HDCP is destroyed but theproperty_validate_dwork queue is still running.[How]Cancel the delayed work when destroying workqueue.(cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmdAfter the hci sync command releases l2cap_conn, the hci receive data workqueue references the released l2cap_conn when sending to the upper layer.Add hci dev lock to the hci receive data work queue to synchronize the two.[1]BUG: KASAN: slab-use-after-free in l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954Read of size 8 at addr ffff8880271a4000 by task kworker/u9:2/5837CPU: 0 UID: 0 PID: 5837 Comm: kworker/u9:2 Not tainted 6.13.0-rc5-syzkaller-00163-gab75170520d4 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: hci1 hci_rx_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 l2cap_build_cmd net/bluetooth/l2cap_core.c:2964 [inline] l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954 l2cap_sig_send_rej net/bluetooth/l2cap_core.c:5502 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5538 [inline] l2cap_recv_frame+0x221f/0x10db0 net/bluetooth/l2cap_core.c:6817 hci_acldata_packet net/bluetooth/hci_core.c:3797 [inline] hci_rx_work+0x508/0xdb0 net/bluetooth/hci_core.c:4040 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 5837: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] l2cap_conn_add+0xa9/0x8e0 net/bluetooth/l2cap_core.c:6860 l2cap_connect_cfm+0x115/0x1090 net/bluetooth/l2cap_core.c:7239 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline] hci_remote_features_evt+0x68e/0xac0 net/bluetooth/hci_event.c:3726 hci_event_func net/bluetooth/hci_event.c:7473 [inline] hci_event_packet+0xac2/0x1540 net/bluetooth/hci_event.c:7525 hci_rx_work+0x3f3/0xdb0 net/bluetooth/hci_core.c:4035 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244Freed by task 54: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 l2cap_connect_cfm+0xcc/0x1090 net/bluetooth/l2cap_core.c:7235 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline] hci_conn_failed+0x287/0x400 net/bluetooth/hci_conn.c:1266 hci_abort_conn_sync+0x56c/0x11f0 net/bluetooth/hci_sync.c:5603 hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Bridge, fix the crash caused by LAG state checkWhen removing LAG device from bridge, NETDEV_CHANGEUPPER event istriggered. Driver finds the lower devices (PFs) to flush all theoffloaded entries. And mlx5_lag_is_shared_fdb is checked, it returnsfalse if one of PF is unloaded. In such case,mlx5_esw_bridge_lag_rep_get() and its caller return NULL, instead ofthe alive PF, and the flush is skipped.Besides, the bridge fdb entry's lastuse is updated in mlx5 bridgeevent handler. But this SWITCHDEV_FDB_ADD_TO_BRIDGE event can beignored in this case because the upper interface for bond is deleted,and the entry will never be aged because lastuse is never updated.To make things worse, as the entry is alive, mlx5 bridge workqueuekeeps sending that event, which is then handled by kernel bridgenotifier. It causes the following crash when accessing the passed bondnetdev which is already destroyed.To fix this issue, remove such checks. LAG state is already checked incommit 15f8f168952f ("net/mlx5: Bridge, verify LAG state when addingbond to bridge"), driver still need to skip offload if LAG becomesinvalid state after initialization. Oops: stack segment: 0000 [#1] SMP CPU: 3 UID: 0 PID: 23695 Comm: kworker/u40:3 Tainted: G OE 6.11.0_mlnx #1 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_bridge_wq mlx5_esw_bridge_update_work [mlx5_core] RIP: 0010:br_switchdev_event+0x2c/0x110 [bridge] Code: 44 00 00 48 8b 02 48 f7 00 00 02 00 00 74 69 41 54 55 53 48 83 ec 08 48 8b a8 08 01 00 00 48 85 ed 74 4a 48 83 fe 02 48 89 d3 <4c> 8b 65 00 74 23 76 49 48 83 fe 05 74 7e 48 83 fe 06 75 2f 0f b7 RSP: 0018:ffffc900092cfda0 EFLAGS: 00010297 RAX: ffff888123bfe000 RBX: ffffc900092cfe08 RCX: 00000000ffffffff RDX: ffffc900092cfe08 RSI: 0000000000000001 RDI: ffffffffa0c585f0 RBP: 6669746f6e690a30 R08: 0000000000000000 R09: ffff888123ae92c8 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888123ae9c60 R13: 0000000000000001 R14: ffffc900092cfe08 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f15914c8734 CR3: 0000000002830005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __die_body+0x1a/0x60 ? die+0x38/0x60 ? do_trap+0x10b/0x120 ? do_error_trap+0x64/0xa0 ? exc_stack_segment+0x33/0x50 ? asm_exc_stack_segment+0x22/0x30 ? br_switchdev_event+0x2c/0x110 [bridge] ? sched_balance_newidle.isra.149+0x248/0x390 notifier_call_chain+0x4b/0xa0 atomic_notifier_call_chain+0x16/0x20 mlx5_esw_bridge_update+0xec/0x170 [mlx5_core] mlx5_esw_bridge_update_work+0x19/0x40 [mlx5_core] process_scheduled_works+0x81/0x390 worker_thread+0x106/0x250 ? bh_worker+0x110/0x110 kthread+0xb7/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: handle errors in mlx5_chains_create_table()In mlx5_chains_create_table(), the return value of mlx5_get_fdb_sub_ns()and mlx5_get_flow_namespace() must be checked to prevent NULL pointerdereferences. If either function fails, the function should log errormessage with mlx5_core_warn() and return error pointer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/hyperv: Fix address space leak when Hyper-V DRM device is removedWhen a Hyper-V DRM device is probed, the driver allocates MMIO space forthe vram, and maps it cacheable. If the device removed, or in the errorpath for device probing, the MMIO space is released but no unmap is done.Consequently the kernel address space for the mapping is leaked.Fix this by adding iounmap() calls in the device removal path, and in theerror path during device probing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched: address a potential NULL pointer dereference in the GRED scheduler.If kzalloc in gred_init returns a NULL pointer, the code follows theerror handling path, invoking gred_destroy. This, in turn, callsgred_offload, where memset could receive a NULL pointer as input,potentially leading to a kernel crash.When table->opt is NULL in gred_init(), gred_change_table_def()is not called yet, so it is not necessary to call ->ndo_setup_tc()in gred_offload().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodesCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves theirCPU masks and unconditionally accesses per-CPU data for the first CPU of eachmask.According to Documentation/admin-guide/mm/numaperf.rst: "Some memory may share the same node as a CPU, and others are provided as memory only nodes."Therefore, some node CPU masks may be empty and wouldn't have a "first CPU".On a machine with far memory (and therefore CPU-less NUMA nodes):- cpumask_of_node(nid) is 0- cpumask_first(0) is CONFIG_NR_CPUS- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an index that is 1 out of boundsThis does not have any security implications since flashing microcode isa privileged operation but I believe this has reliability implications bypotentially corrupting memory while flashing a microcode update.When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashesa microcode update. I get the following splat: UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y index 512 is out of range for type 'unsigned long[512]' [...] Call Trace: dump_stack __ubsan_handle_out_of_bounds load_microcode_amd request_microcode_amd reload_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframeChange the loop to go over only NUMA nodes which have CPUs before determiningwhether the first CPU on the respective node needs microcode update. [ bp: Massage commit message, fix typo. ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: ignore non-functional sensor in HP 5MP CameraThe HP 5MP Camera (USB ID 0408:5473) reports a HID sensor interface thatis not actually implemented. Attempting to access this non-functionalsensor via iio_info causes system hangs as runtime PM tries to wake upan unresponsive sensor. [453] hid-sensor-hub 0003:0408:5473.0003: Report latency attributes: ffffffff:ffffffff [453] hid-sensor-hub 0003:0408:5473.0003: common attributes: 5:1, 2:1, 3:1 ffffffff:ffffffffAdd this device to the HID ignore list since the sensor interface isnon-functional by design and should not be exposed to userspace.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()When performing an iSCSI boot using IPv6, iscsistart still reads the/sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefixlength is 64, this causes the shift exponent to become negative,triggering a UBSAN warning. As the concept of a subnet mask does notapply to IPv6, the value is set to ~0 to suppress the warning message.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: fix uninitialized size issue in radeon_vce_cs_parse()On the off chance that command stream passed from userspace viaioctl() call to radeon_vce_cs_parse() is weirdly crafted andfirst command to execute is to encode (case 0x03000001), the functionin question will attempt to call radeon_vce_cs_reloc() with sizeargument that has not been properly initialized. Specifically, 'size'will point to 'tmp' variable before the latter had a chance to beassigned any value.Play it safe and init 'tmp' with 0, thus ensuring thatradeon_vce_cs_reloc() will catch an early error in cases like these.Found by Linux Verification Center (linuxtesting.org) with staticanalysis tool SVACE.(cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xsk: fix an integer overflow in xp_create_and_assign_umem()Since the i and pool->chunk_size variables are of type 'u32',their product can wrap around and then be cast to 'u64'.This can lead to two different XDP buffers pointing to the samememory area.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: ucan: fix out of bound read in strscpy() sourceCommit 7fdaf8966aae ("can: ucan: use strscpy() to instead of strncpy()")unintentionally introduced a one byte out of bound read on strscpy()'ssource argument (which is kind of ironic knowing that strscpy() is meantto be a more secure alternative :)).Let's consider below buffers: dest[len + 1]; /* will be NUL terminated */ src[len]; /* may not be NUL terminated */When doing: strncpy(dest, src, len); dest[len] = '\0';strncpy() will read up to len bytes from src.On the other hand: strscpy(dest, src, len + 1);will read up to len + 1 bytes from src, that is to say, an out of boundread of one byte will occur on src if it is not NUL terminated. Notethat the src[len] byte is never copied, but strscpy() still needs toread it to check whether a truncation occurred or not.This exact pattern happened in ucan.The root cause is that the source is not NUL terminated. Instead ofdoing a copy in a local buffer, directly NUL terminate it as soon asusb_control_msg() returns. With this, the local firmware_str[] variablecan be removed.On top of this do a couple refactors: - ucan_ctl_payload->raw is only used for the firmware string, so rename it to ucan_ctl_payload->fw_str and change its type from u8 to char. - ucan_device_request_in() is only used to retrieve the firmware string, so rename it to ucan_get_fw_str() and refactor it to make it directly handle all the string termination logic.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everythingwhen it fails.Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh")moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output incase it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak.Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in theerror path.Note that we can remove the fib6_nh_release() call in nh_create_ipv6()later in net-next.git.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix error code in chan_alloc_skb_cb()The chan_alloc_skb_cb() function is supposed to return error pointers onerror. Returning NULL will lead to a NULL dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: check that dummy regulator has been probed before using itDue to asynchronous driver probing there is a chance that the dummyregulator hasn't already been probed when first accessing it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix soft lockup during bt pages loopDriver runs a for-loop when allocating bt pages and mapping them withbuffer pages. When a large buffer (e.g. MR over 100GB) is being allocated,it may require a considerable loop count. This will lead to soft lockup: watchdog: BUG: soft lockup - CPU#27 stuck for 22s! ... Call trace: hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2] hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2] hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2] alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2] hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x118/0x290 watchdog: BUG: soft lockup - CPU#35 stuck for 23s! ... Call trace: hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2] mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2] hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2] alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2] hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x120/0x2bcAdd a cond_resched() to fix soft lockup during these loops. In order notto affect the allocation performance of normal-size buffer, set the loopcount of a 100GB MR as the threshold to call cond_resched().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: pdr: Fix the potential deadlockWhen some client process A call pdr_add_lookup() to add the look up forthe service and does schedule locator work, later a process B got a newserver packet indicating locator is up and call pdr_locator_new_server()which eventually sets pdr->locator_init_complete to true which process Asees and takes list lock and queries domain list but it will timeout dueto deadlock as the response will queued to the same qmi->wq and it isordered workqueue and process B is not able to complete new serverrequest work due to deadlock on list lock.Fix it by removing the unnecessary list iteration as the list iterationis already being done inside locator work, so avoid it here and justcall schedule_work() here. Process A Process B process_scheduled_works()pdr_add_lookup() qmi_data_ready_work() process_scheduled_works() pdr_locator_new_server() pdr->locator_init_complete=true; pdr_locator_work() mutex_lock(&pdr->list_lock); pdr_locate_service() mutex_lock(&pdr->list_lock); pdr_get_domain_list() pr_err("PDR: %s get domain list txn wait failed: %d\n", req->service_name, ret);Timeout error log due to deadlock:" PDR: tms/servreg get domain list txn wait failed: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110"Thanks to Bjorn and Johan for letting me know that this commit also fixesan audio regression when using the in-kernel pd-mapper as that makes iteasier to hit this race. [1]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: Fix NULL pointer dereferenceWhen MPOA_cache_impos_rcvd() receives the msg, it can triggerNull Pointer Dereference Vulnerability if both entry andholding_time are NULL. Because there is only for the situationwhere entry is NULL and holding_time exists, it can be passedwhen both entry and holding_time are NULL. If these are NULL,the entry will be passd to eg_cache_put() as parameter andit is referenced by entry->use code in it.kasan log:[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037][ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0[ 3.326430] Call Trace:[ 3.326725] [ 3.326927] ? die_addr+0x3c/0xa0[ 3.327330] ? exc_general_protection+0x161/0x2a0[ 3.327662] ? asm_exc_general_protection+0x26/0x30[ 3.328214] ? vprintk_emit+0x15e/0x420[ 3.328543] ? eg_cache_remove_entry+0xa5/0x470[ 3.328910] ? eg_cache_remove_entry+0x9a/0x470[ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10[ 3.329664] ? console_unlock+0x107/0x1d0[ 3.329946] ? __pfx_console_unlock+0x10/0x10[ 3.330283] ? do_syscall_64+0xa6/0x1a0[ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f[ 3.331090] ? __pfx_prb_read_valid+0x10/0x10[ 3.331395] ? down_trylock+0x52/0x80[ 3.331703] ? vprintk_emit+0x15e/0x420[ 3.331986] ? __pfx_vprintk_emit+0x10/0x10[ 3.332279] ? down_trylock+0x52/0x80[ 3.332527] ? _printk+0xbf/0x100[ 3.332762] ? __pfx__printk+0x10/0x10[ 3.333007] ? _raw_write_lock_irq+0x81/0xe0[ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10[ 3.333614] msg_from_mpoad+0x1185/0x2750[ 3.333893] ? __build_skb_around+0x27b/0x3a0[ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10[ 3.334501] ? __alloc_skb+0x1c0/0x310[ 3.334809] ? __pfx___alloc_skb+0x10/0x10[ 3.335283] ? _raw_spin_lock+0xe0/0xe0[ 3.335632] ? finish_wait+0x8d/0x1e0[ 3.335975] vcc_sendmsg+0x684/0xba0[ 3.336250] ? __pfx_vcc_sendmsg+0x10/0x10[ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10[ 3.337056] ? fdget+0x176/0x3e0[ 3.337348] __sys_sendto+0x4a2/0x510[ 3.337663] ? __pfx___sys_sendto+0x10/0x10[ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400[ 3.338364] ? sock_ioctl+0x1bb/0x5a0[ 3.338653] ? __rseq_handle_notify_resume+0x825/0xd20[ 3.339017] ? __pfx_sock_ioctl+0x10/0x10[ 3.339316] ? __pfx___rseq_handle_notify_resume+0x10/0x10[ 3.339727] ? selinux_file_ioctl+0xa4/0x260[ 3.340166] __x64_sys_sendto+0xe0/0x1c0[ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140[ 3.340898] do_syscall_64+0xa6/0x1a0[ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 3.341533] RIP: 0033:0x44a380[ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00[ ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: vimc: skip .s_stream() for stopped entitiesSyzbot reported [1] a warning prompted by a check in call_s_stream()that checks whether .s_stream() operation is warranted for unstartedor stopped subdevs.Add a simple fix in vimc_streamer_pipeline_terminate() ensuring thatentities skip a call to .s_stream() unless they have been previouslyproperly started.[1] Syzbot report:------------[ cut here ]------------WARNING: CPU: 0 PID: 5933 at drivers/media/v4l2-core/v4l2-subdev.c:460 call_s_stream+0x2df/0x350 drivers/media/v4l2-core/v4l2-subdev.c:460Modules linked in:CPU: 0 UID: 0 PID: 5933 Comm: syz-executor330 Not tainted 6.13.0-rc2-syzkaller-00362-g2d8308bf5b67 #0...Call Trace: vimc_streamer_pipeline_terminate+0x218/0x320 drivers/media/test-drivers/vimc/vimc-streamer.c:62 vimc_streamer_pipeline_init drivers/media/test-drivers/vimc/vimc-streamer.c:101 [inline] vimc_streamer_s_stream+0x650/0x9a0 drivers/media/test-drivers/vimc/vimc-streamer.c:203 vimc_capture_start_streaming+0xa1/0x130 drivers/media/test-drivers/vimc/vimc-capture.c:256 vb2_start_streaming+0x15f/0x5a0 drivers/media/common/videobuf2/videobuf2-core.c:1789 vb2_core_streamon+0x2a7/0x450 drivers/media/common/videobuf2/videobuf2-core.c:2348 vb2_streamon drivers/media/common/videobuf2/videobuf2-v4l2.c:875 [inline] vb2_ioctl_streamon+0xf4/0x170 drivers/media/common/videobuf2/videobuf2-v4l2.c:1118 __video_do_ioctl+0xaf0/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3122 video_usercopy+0x4d2/0x1620 drivers/media/v4l2-core/v4l2-ioctl.c:3463 v4l2_ioctl+0x1ba/0x250 drivers/media/v4l2-core/v4l2-dev.c:366 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f2b85c01b19...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:acpi: nfit: fix narrowing conversion in acpi_nfit_ctlSyzkaller has reported a warning in to_nfit_bus_uuid(): "only secondarybus families can be translated". This warning is emited if the argumentis equal to NVDIMM_BUS_FAMILY_NFIT == 0. Function acpi_nfit_ctl() firstverifies that a user-provided value call_pkg->nd_family of type u64 isnot equal to 0. Then the value is converted to int, and only after thatis compared to NVDIMM_BUS_FAMILY_MAX. This can lead to passing an invalidargument to acpi_nfit_ctl(), if call_pkg->nd_family is non-zero, whilethe lower 32 bits are zero.Furthermore, it is best to return EINVAL immediately upon seeing theinvalid user input. The WARNING is insufficient to prevent furtherundefined behavior based on other invalid user input.All checks of the input value should be applied to the original variablecall_pkg->nd_family.[iweiny: update commit message]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet:fix NPE during rx_completeMissing usbnet_going_away Check in Critical Path.The usb_submit_urb function lacks a usbnet_going_awayvalidation, whereas __usbnet_queue_skb includes this check.This inconsistency creates a race condition where:A URB request may succeed, but the corresponding SKB datafails to be queued.Subsequent processes:(e.g., rx_complete -> defer_bh -> __skb_unlink(skb, list))attempt to access skb->next, triggering a NULL pointerdereference (Kernel Panic).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ibmveth: make veth_pool_store stop hangingv2:- Created a single error handling unlock and exit in veth_pool_store- Greatly expanded commit message with previous explanatory-only textSummary: Use rtnl_mutex to synchronize veth_pool_store with itself,ibmveth_close and ibmveth_open, preventing multiple calls in a row tonapi_disable.Background: Two (or more) threads could call veth_pool_store throughwriting to /sys/devices/vio/30000002/pool*/*. You can do this easilywith a little shell script. This causes a hang.I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a newkernel. I ran this test again and saw: Setting pool0/active to 0 Setting pool1/active to 1 [ 73.911067][ T4365] ibmveth 30000002 eth0: close starting Setting pool1/active to 1 Setting pool1/active to 0 [ 73.911367][ T4366] ibmveth 30000002 eth0: close starting [ 73.916056][ T4365] ibmveth 30000002 eth0: close complete [ 73.916064][ T4365] ibmveth 30000002 eth0: open starting [ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds. [ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8 [ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 task_flags:0x400040 flags:0x00042000 [ 243.683852][ T123] Call Trace: [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable) [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0 [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0 [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210 [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50 [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0 [ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60 [ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc [ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270 [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0 [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0 [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650 [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150 [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340 [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec ... [ 243.684087][ T123] Showing all locks held in the system: [ 243.684095][ T123] 1 lock held by khungtaskd/123: [ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248 [ 243.684114][ T123] 4 locks held by stress.sh/4365: [ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0 [ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0 [ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60 [ 243.684166][ T123] 5 locks held by stress.sh/4366: [ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mvpp2: Prevent parser TCAM memory corruptionProtect the parser TCAM/SRAM memory, and the cached (shadow) SRAMinformation, from concurrent modifications.Both the TCAM and SRAM tables are indirectly accessed by configuringan index register that selects the row to read or write to. This meansthat operations must be atomic in order to, e.g., avoid spreadingwrites across multiple rows. Since the shadow SRAM array is used tofind free rows in the hardware table, it must also be protected inorder to avoid TOCTOU errors where multiple cores allocate the samerow.This issue was detected in a situation where `mvpp2_set_rx_mode()` ranconcurrently on two CPUs. In this particular case theMVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing theclassifier unit to drop all incoming unicast - indicated by the`rx_classifier_drops` counter.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: add mutual exclusion in proc_sctp_do_udp_port()We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start()or risk a crash as syzbot reported:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653Call Trace: udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181 sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930 proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553 proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601 iter_file_splice_write+0x91c/0x1150 fs/splice.c:738 do_splice_from fs/splice.c:935 [inline] direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158 splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102 do_splice_direct_actor fs/splice.c:1201 [inline] do_splice_direct+0x174/0x240 fs/splice.c:1227 do_sendfile+0xafd/0xe50 fs/read_write.c:1368 __do_sys_sendfile64 fs/read_write.c:1429 [inline] __se_sys_sendfile64 fs/read_write.c:1415 [inline] __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: imx-card: Add NULL check in imx_card_probe()devm_kasprintf() returns NULL when memory allocation fails. Currently,imx_card_probe() does not check for this case, which results in a NULLpointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spufs: fix gang directory lifetimesprior to "[POWERPC] spufs: Fix gang destroy leaks" we used to havea problem with gang lifetimes - creation of a gang returns openedgang directory, which normally gets removed when that gets closed,but if somebody has created a context belonging to that gang andkept it alive until the gang got closed, removal failed and weended up with a leak.Unfortunately, it had been fixed the wrong way. Dentry of gangdirectory was no longer pinned, and rmdir on close was gone.One problem was that failure of open kept calling simple_rmdir()as cleanup, which meant an unbalanced dput(). Another bug wasin the success case - gang creation incremented link count onroot directory, but that was no longer undone when gang gotdestroyed.Fix consists of * reverting the commit in question * adding a counter to gang, protected by ->i_rwsemof gang directory inode. * having it set to 1 at creation time, droppedin both spufs_dir_close() and spufs_gang_close() and bumpedin spufs_create_context(), provided that it's not 0. * using simple_recursive_removal() to take the gangdirectory out when counter reaches zero.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rtnetlink: Allocate vfinfo size for VF GUIDs when supportedCommit 30aad41721e0 ("net/core: Add support for getting VF GUIDs")added support for getting VF port and node GUIDs in netlink ifinfomessages, but their size was not taken into consideration in thefunction that allocates the netlink message, causing the followingwarning when a netlink message is filled with many VF port and nodeGUIDs: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link show dev ib0 RTNETLINK answers: Message too long Cannot send link get request: Message too longKernel warning: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0 Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnl_getlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __warn+0xa5/0x230 ? rtnl_getlink+0x586/0x5a0 ? report_bug+0x22d/0x240 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_trim+0x6a/0x80 ? rtnl_getlink+0x586/0x5a0 ? __pfx_rtnl_getlink+0x10/0x10 ? rtnetlink_rcv_msg+0x1e5/0x860 ? __pfx___mutex_lock+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx_lock_acquire+0x10/0x10 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1d/0x70 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 rtnetlink_rcv_msg+0x21c/0x860 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? arch_stack_walk+0x9e/0xf0 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 ? rcu_is_watching+0x34/0x60 netlink_rcv_skb+0xe0/0x210 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx___netlink_lookup+0x10/0x10 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0xfd/0x290 ? rcu_is_watching+0x34/0x60 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0x95/0x290 netlink_unicast+0x31f/0x480 ? __pfx_netlink_unicast+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 netlink_sendmsg+0x369/0x660 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ? import_ubuf+0xb9/0xf0 ? __import_iovec+0x254/0x2b0 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ____sys_sendmsg+0x559/0x5a0 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? do_read_fault+0x213/0x4a0 ? rcu_is_watching+0x34/0x60 ___sys_sendmsg+0xe4/0x150 ? __pfx____sys_sendmsg+0x10/0x10 ? do_fault+0x2cc/0x6f0 ? handle_pte_fault+0x2e3/0x3d0 ? __pfx_handle_pte_fault+0x10/0x10---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Revert "smb: client: fix TCP timers deadlock after rmmod"This reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.Commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock afterrmmod") is intended to fix a null-ptr-deref in LOCKDEP, which ismentioned as CVE-2024-54680, but is actually did not fix anything;The issue can be reproduced on top of it. [0]Also, it reverted the change by commit ef7134c7fc48 ("smb: client:Fix use-after-free of network namespace.") and introduced a realissue by reviving the kernel TCP socket.When a reconnect happens for a CIFS connection, the socket statetransitions to FIN_WAIT_1. Then, inet_csk_clear_xmit_timers_sync()in tcp_close() stops all timers for the socket.If an incoming FIN packet is lost, the socket will stay at FIN_WAIT_1forever, and such sockets could be leaked up to net.ipv4.tcp_max_orphans.Usually, FIN can be retransmitted by the peer, but if the peer abortsthe connection, the issue comes into reality.I warned about this privately by pointing out the exact report [1],but the bogus fix was finally merged.So, we should not stop the timers to finally kill the connection onour side in that case, meaning we must not use a kernel socket forTCP whose sk->sk_net_refcnt is 0.The kernel socket does not have a reference to its netns to make itpossible to tear down netns without cleaning up every resource in it.For example, tunnel devices use a UDP socket internally, but we candestroy netns without removing such devices and let it completeduring exit. Otherwise, netns would be leaked when the last applicationdied.However, this is problematic for TCP sockets because TCP has timers toclose the connection gracefully even after the socket is close()d. Thelifetime of the socket and its netns is different from the lifetime ofthe underlying connection.If the socket user does not maintain the netns lifetime, the timer couldbe fired after the socket is close()d and its netns is freed up, resultingin use-after-free.Actually, we have seen so many similar issues and converted such socketsto have a reference to netns.That's why I converted the CIFS client socket to have a reference tonetns (sk->sk_net_refcnt == 1), which is somehow mentioned as out-of-scopeof CIFS and technically wrong in e9f2517a3e18, but **is in-scope and rightfix**.Regarding the LOCKDEP issue, we can prevent the module unload bybumping the module refcount when switching the LOCKDDEP key insock_lock_init_class_and_name(). [2]For a while, let's revert the bogus fix.Note that now we can use sk_net_refcnt_upgrade() for the socketconversion, but I'll do so later separately to make backport easy.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpointIf vhost_scsi_set_endpoint is called multiple times without avhost_scsi_clear_endpoint between them, we can hit multiple bugsfound by Haoran Zhang:1. Use-after-free when no tpgs are found:This fixes a use after free that occurs when vhost_scsi_set_endpoint iscalled more than once and calls after the first call do not find anytpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first findstpgs to add to the vs_tpg array match=true, so we will do:vhost_vq_set_backend(vq, vs_tpg);...kfree(vs->vs_tpg);vs->vs_tpg = vs_tpg;If vhost_scsi_set_endpoint is called again and no tpgs are foundmatch=false so we skip the vhost_vq_set_backend call leaving thepointer to the vs_tpg we then free via:kfree(vs->vs_tpg);vs->vs_tpg = vs_tpg;If a scsi request is then sent we do:vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backendwhich sees the vs_tpg we just did a kfree on.2. Tpg dir removal hang:This patch fixes an issue where we cannot remove a LIO/target layertpg (and structs above it like the target) dir due to the refcountdropping to -1.The problem is that if vhost_scsi_set_endpoint detects a tpg is alreadyin the vs->vs_tpg array or if the tpg has been removed sotarget_depend_item fails, the undepend goto handler will dotarget_undepend_item on all tpgs in the vs_tpg array dropping theirrefcount to 0. At this time vs_tpg contains both the tpgs we have addedin the current vhost_scsi_set_endpoint call as well as tpgs we added inprevious calls which are also in vs->vs_tpg.Later, when vhost_scsi_clear_endpoint runs it will dotarget_undepend_item on all the tpgs in the vs->vs_tpg which will droptheir refcount to -1. Userspace will then not be able to remove the tpgand will hang when it tries to do rmdir on the tpg dir.3. Tpg leak:This fixes a bug where we can leak tpgs and cause them to beun-removable because the target name is overwritten whenvhost_scsi_set_endpoint is called multiple times but with differenttarget names.The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setupa vhost-scsi device to target/tpg mapping, then callsVHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs wehaven't seen before (target1 has tpg1 but target2 has tpg2). When thishappens we don't teardown the old target tpg mapping and just overwritethe target name and the vs->vs_tpg array. Later when we dovhost_scsi_clear_endpoint, we are passed in either target1 or target2'sname and we will only match that target's tpgs when we loop over thevs->vs_tpg. We will then return from the function without doingtarget_undepend_item on the tpgs.Because of all these bugs, it looks like being able to callvhost_scsi_set_endpoint multiple times was never supported. The majoruser, QEMU, already has checks to prevent this use case. So to fix theissues, this patch prevents vhost_scsi_set_endpoint from being calledif it's already successfully added tpgs. To add, remove or change thetpg config or target name, you must do a vhost_scsi_clear_endpointfirst.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flowWhen cur_qp isn't NULL, in order to avoid fetching the QP fromthe radix tree again we check if the next cqe QP is identical tothe one we already have.The bug however is that we are checking if the QP is identical bychecking the QP number inside the CQE against the QP number inside themlx5_ib_qp, but that's wrong since the QP number from the CQE is fromFW so it should be matched against mlx5_core_qp which is our FW QPnumber.Otherwise we could use the wrong QP when handling a CQE which couldcause the kernel trace below.This issue is mainly noticeable over QPs 0 & 1, since for now they arethe only QPs in our driver whereas the QP number inside mlx5_ib_qpdoesn't match the QP number inside mlx5_core_qp.BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] __ib_process_cq+0x5a/0x150 [ib_core] ib_cq_poll_work+0x31/0x90 [ib_core] process_one_work+0x169/0x320 worker_thread+0x288/0x3a0 ? work_busy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreads_online_cpu+0x130/0x130 ? kthreads_online_cpu+0x130/0x130 ret_from_fork+0x2d/0x50 ? kthreads_online_cpu+0x130/0x130 ret_from_fork_asm+0x11/0x20
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()If track_pfn_copy() fails, we already added the dst VMA to the mapletree. As fork() fails, we'll cleanup the maple tree, and stumble overthe dst VMA for which we neither performed any reservation nor copiedany page tables.Consequently untrack_pfn() will see VM_PAT and try obtaining thePAT information from the page table -- which fails because the pagetable was not copied.The easiest fix would be to simply clear the VM_PAT flag of the dst VMAif track_pfn_copy() fails. However, the whole thing is about "simply"clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy()and performed a reservation, but copying the page tables fails, we'llsimply clear the VM_PAT flag, not properly undoing the reservation ...which is also wrong.So let's fix it properly: set the VM_PAT flag only if the reservationsucceeded (leaving it clear initially), and undo the reservation ifanything goes wrong while copying the page tables: clearing the VM_PATflag after undoing the reservation.Note that any copied page table entries will get zapped when the VMA willget removed later, after copy_page_range() succeeded; as VM_PAT is not setthen, we won't try cleaning VM_PAT up once more and untrack_pfn() will behappy. Note that leaving these page tables in place without a reservationis not a problem, as we are aborting fork(); this process will never run.A reproducer can trigger this usually at the first try: https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 Modules linked in: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:get_pat_info+0xf6/0x110 ... Call Trace: ... untrack_pfn+0x52/0x110 unmap_single_vma+0xa6/0xe0 unmap_vmas+0x105/0x1f0 exit_mmap+0xf6/0x460 __mmput+0x4b/0x120 copy_process+0x1bf6/0x2aa0 kernel_clone+0xab/0x440 __do_sys_clone+0x66/0x90 do_syscall_64+0x95/0x180Likely this case was missed in: d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed")... and instead of undoing the reservation we simply cleared the VM_PAT flag.Keep the documentation of these functions in include/linux/pgtable.h,one place is more than sufficient -- we should clean that up for the otherfunctions like track_pfn_remap/untrack_pfn separately.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: check xdp prog when set bond modeFollowing operations can trigger a warning[1]: ip netns add ns1 ip netns exec ns1 ip link add bond0 type bond mode balance-rr ip netns exec ns1 ip link set dev bond0 xdp obj af_xdp_kern.o sec xdp ip netns exec ns1 ip link set bond0 type bond mode broadcast ip netns del ns1When delete the namespace, dev_xdp_uninstall() is called to remove xdpprogram on bond dev, and bond_xdp_set() will check the bond mode. If bondmode is changed after attaching xdp program, the warning may occur.Some bond modes (broadcast, etc.) do not support native xdp. Set bond modewith xdp program attached is not good. Add check for xdp program when setbond mode. [1] ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at net/core/dev.c:9912 unregister_netdevice_many_notify+0x8d9/0x930 Modules linked in: CPU: 0 UID: 0 PID: 11 Comm: kworker/u4:0 Not tainted 6.14.0-rc4 #107 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:unregister_netdevice_many_notify+0x8d9/0x930 Code: 00 00 48 c7 c6 6f e3 a2 82 48 c7 c7 d0 b3 96 82 e8 9c 10 3e ... RSP: 0018:ffffc90000063d80 EFLAGS: 00000282 RAX: 00000000ffffffa1 RBX: ffff888004959000 RCX: 00000000ffffdfff RDX: 0000000000000000 RSI: 00000000ffffffea RDI: ffffc90000063b48 RBP: ffffc90000063e28 R08: ffffffff82d39b28 R09: 0000000000009ffb R10: 0000000000000175 R11: ffffffff82d09b40 R12: ffff8880049598e8 R13: 0000000000000001 R14: dead000000000100 R15: ffffc90000045000 FS: 0000000000000000(0000) GS:ffff888007a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000d406b60 CR3: 000000000483e000 CR4: 00000000000006f0 Call Trace: ? __warn+0x83/0x130 ? unregister_netdevice_many_notify+0x8d9/0x930 ? report_bug+0x18e/0x1a0 ? handle_bug+0x54/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? unregister_netdevice_many_notify+0x8d9/0x930 ? bond_net_exit_batch_rtnl+0x5c/0x90 cleanup_net+0x237/0x3d0 process_one_work+0x163/0x390 worker_thread+0x293/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0xec/0x1e0 ? __pfx_kthread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ax25: Remove broken autobindBinding AX25 socket by using the autobind feature leads to memory leaksin ax25_connect() and also refcount leaks in ax25_release(). Memoryleak was detected with kmemleak:================================================================unreferenced object 0xffff8880253cd680 (size 96):backtrace:__kmalloc_node_track_caller_noprof (./include/linux/kmemleak.h:43)kmemdup_noprof (mm/util.c:136)ax25_rt_autobind (net/ax25/ax25_route.c:428)ax25_connect (net/ax25/af_ax25.c:1282)__sys_connect_file (net/socket.c:2045)__sys_connect (net/socket.c:2064)__x64_sys_connect (net/socket.c:2067)do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)================================================================When socket is bound, refcounts must be incremented the way it is donein ax25_bind() and ax25_setsockopt() (SO_BINDTODEVICE). In case ofautobind, the refcounts are not incremented.This bug leads to the following issue reported by Syzkaller:================================================================ax25_connect(): syz-executor318 uses autobind, please contact jreuter@yaina.de------------[ cut here ]------------refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 0 PID: 5317 at lib/refcount.c:31 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31Modules linked in:CPU: 0 UID: 0 PID: 5317 Comm: syz-executor318 Not tainted 6.14.0-rc4-syzkaller-00278-gece144f151ac #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31...Call Trace: __refcount_dec include/linux/refcount.h:336 [inline] refcount_dec include/linux/refcount.h:351 [inline] ref_tracker_free+0x6af/0x7e0 lib/ref_tracker.c:236 netdev_tracker_free include/linux/netdevice.h:4302 [inline] netdev_put include/linux/netdevice.h:4319 [inline] ax25_release+0x368/0x960 net/ax25/af_ax25.c:1080 __sock_release net/socket.c:647 [inline] sock_close+0xbc/0x240 net/socket.c:1398 __fput+0x3e9/0x9f0 fs/file_table.c:464 __do_sys_close fs/open.c:1580 [inline] __se_sys_close fs/open.c:1565 [inline] __x64_sys_close+0x7f/0x110 fs/open.c:1565 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... ================================================================Considering the issues above and the comments left in the code that say:"check if we can remove this feature. It is broken."; "autobinding in thismay or may not work"; - it is better to completely remove this feature thanto fix it because it is broken and leads to various kinds of memory bugs.Now calling connect() without first binding socket will result in anerror (-EINVAL). Userspace software that relies on the autobind featuremight get broken. However, this feature does not seem widely used withthis specific driver as it was not reliable at any point of time, and itis already broken anyway. E.g. ax25-tools and ax25-apps packages forpopular distributions do not use the autobind feature for AF_AX25.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()There's issue as follows:BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172CPU: 3 PID: 15172 Comm: syz-executor.0Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0xbe/0xfd lib/dump_stack.c:123 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323 evict+0x39f/0x880 fs/inode.c:622 iput_final fs/inode.c:1746 [inline] iput fs/inode.c:1772 [inline] iput+0x525/0x6c0 fs/inode.c:1758 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline] ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300 mount_bdev+0x355/0x410 fs/super.c:1446 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576 do_new_mount fs/namespace.c:2983 [inline] path_mount+0x119a/0x1ad0 fs/namespace.c:3316 do_mount+0xfc/0x110 fs/namespace.c:3329 __do_sys_mount fs/namespace.c:3540 [inline] __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1Memory state around the buggy address: ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffAbove issue happens as ext4_xattr_delete_inode() isn't check xattris valid if xattr is in inode.To solve above issue call xattr_check_inode() check if xattr if validin inode. In fact, we can directly verify in ext4_iget_extra_inode(),so that there is no divergent verification.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid1,raid10: don't ignore IO flagsIf blk-wbt is enabled by default, it's found that raid write performanceis quite bad because all IO are throttled by wbt of underlying disks,due to flag REQ_IDLE is ignored. And turns out this behaviour exist sinceblk-wbt is introduced.Other than REQ_IDLE, other flags should not be ignored as well, forexample REQ_META can be set for filesystems, clearing it can cause priorityreverse problems; And REQ_NOWAIT should not be cleared as well, becauseio will wait instead of failing directly in underlying disks.Fix those problems by keep IO flags from master bio.Fises: f51d46d0e7cb ("md: add support for REQ_NOWAIT")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq() in error pathIf a shared IRQ is used by the driver due to platform limitation, then theIRQ affinity hint is set right after the allocation of IRQ vectors inath11k_pci_alloc_msi(). This does no harm unless one of the functionsrequesting the IRQ fails and attempt to free the IRQ. This results in thebelow warning:WARNING: CPU: 7 PID: 349 at kernel/irq/manage.c:1929 free_irq+0x278/0x29cCall trace: free_irq+0x278/0x29c ath11k_pcic_free_irq+0x70/0x10c [ath11k] ath11k_pci_probe+0x800/0x820 [ath11k_pci] local_pci_probe+0x40/0xbcThe warning is due to not clearing the affinity hint before freeing theIRQs.So to fix this issue, clear the IRQ affinity hint before callingath11k_pcic_free_irq() in the error path. The affinity will be cleared onceagain further down the error path due to code organization, but that doesno harm.Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dlm: prevent NPD when writing a positive value to event_donedo_uevent returns the value written to event_done. In case it is apositive value, new_lockspace would undo all the work, and lockspacewould not be set. __dlm_new_lockspace, however, would treat thatpositive value as a success due to commit 8511a2728ab8 ("dlm: fix usecount with multiple joins").Down the line, device_create_lockspace would pass that NULL lockspace todlm_find_lockspace_local, leading to a NULL pointer dereference.Treating such positive values as successes prevents the problem. Giventhis has been broken for so long, this is unlikely to break userspaceexpectations.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:thermal: int340x: Add NULL check for adevNot all devices have an ACPI companion fwnode, so adev might be NULL.This is similar to the commit cd2fd6eab480("platform/x86: int3472: Check for adev == NULL").Add a check for adev not being set and return -ENODEV in that case toavoid a possible NULL pointer deref in int3402_thermal_probe().Note, under the same directory, int3400_thermal_probe() has such acheck.[ rjw: Subject edit, added Fixes: ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:misc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq errorAfter devm_request_irq() fails with error in pci_endpoint_test_request_irq(),the pci_endpoint_test_free_irq_vectors() is called assuming that all IRQshave been released.However, some requested IRQs remain unreleased, so there are still/proc/irq/* entries remaining, and this results in WARN() with thefollowing message: remove_proc_entry: removing non-empty directory 'irq/30', leaking at least 'pci-endpoint-test.0' WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19cTo solve this issue, set the number of remaining IRQs to test->num_irqs,and release IRQs in advance by calling pci_endpoint_test_release_irq().[kwilczynski: commit log]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: detect and prevent references to a freed transport in sendmsgsctp_sendmsg() re-uses associations and transports when possible bydoing a lookup based on the socket endpoint and the message destinationaddress, and then sctp_sendmsg_to_asoc() sets the selected transport inall the message chunks to be sent.There's a possible race condition if another thread triggers the removalof that selected transport, for instance, by explicitly unbinding anaddress with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks havebeen set up and before the message is sent. This can happen if the sendbuffer is full, during the period when the sender thread temporarilyreleases the socket lock in sctp_wait_for_sndbuf().This causes the access to the transport data insctp_outq_select_transport(), when the association outqueue is flushed,to result in a use-after-free read.This change avoids this scenario by having sctp_transport_free() signalthe freeing of the transport, tagging it as "dead". In order to do this,the patch restores the "dead" bit in struct sctp_transport, which wasremoved incommit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").Then, in the scenario where the sender thread has released the socketlock in sctp_wait_for_sndbuf(), the bit is checked again afterre-acquiring the socket lock to detect the deletion. This is done whileholding a reference to the transport to prevent it from being freed inthe process.If the transport was deleted while the socket lock was relinquished,sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry thesend.The bug was found by a private syzbot instance (see the error report [1]and the C reproducer that triggers it [2]).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod.When I ran the repro [0] and waited a few seconds, I observed twoLOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1]Reproduction Steps: 1) Mount CIFS 2) Add an iptables rule to drop incoming FIN packets for CIFS 3) Unmount CIFS 4) Unload the CIFS module 5) Remove the iptables ruleAt step 3), the CIFS module calls sock_release() for the underlyingTCP socket, and it returns quickly. However, the socket remains inFIN_WAIT_1 because incoming FIN packets are dropped.At this point, the module's refcnt is 0 while the socket is stillalive, so the following rmmod command succeeds. # ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445 # lsmod | grep cifs cifs 1159168 0This highlights a discrepancy between the lifetime of the CIFS moduleand the underlying TCP socket. Even after CIFS calls sock_release()and it returns, the TCP socket does not die immediately in order toclose the connection gracefully.While this is generally fine, it causes an issue with LOCKDEP becauseCIFS assigns a different lock class to the TCP socket's sk->sk_lockusing sock_lock_init_class_and_name().Once an incoming packet is processed for the socket or a timer fires,sk->sk_lock is acquired.Then, LOCKDEP checks the lock context in check_wait_context(), wherehlock_class() is called to retrieve the lock class. However, sincethe module has already been unloaded, hlock_class() logs a warningand returns NULL, triggering the null-ptr-deref.If LOCKDEP is enabled, we must ensure that a module callingsock_lock_init_class_and_name() (CIFS, NFS, etc) cannot be unloadedwhile such a socket is still alive to prevent this issue.Let's hold the module reference in sock_lock_init_class_and_name()and release it when the socket is freed in sk_prot_free().Note that sock_lock_init() clears sk->sk_owner for svc_create_socket()that calls sock_lock_init_class_and_name() for a listening socket,which clones a socket by sk_clone_lock() without GFP_ZERO.[0]:CIFS_SERVER="10.0.0.137"CIFS_PATH="//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST"DEV="enp0s3"CRED="/root/WindowsCredential.txt"MNT=$(mktemp -d /tmp/XXXXXX)mount -t cifs ${CIFS_PATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echo_interval=1iptables -A INPUT -s ${CIFS_SERVER} -j DROPfor i in $(seq 10);do umount ${MNT} rmmod cifs sleep 1donerm -r ${MNT}iptables -D INPUT -s ${CIFS_SERVER} -j DROP[1]:DEBUG_LOCKS_WARN_ON(1)WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)Modules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs]CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)...Call Trace: __lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) _raw_spin_lock_nested (kernel/locking/spinlock.c:379) tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350)...BUG: kernel NULL pointer dereference, address: 00000000000000c4 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 0Oops: Oops: 0000 [#1] PREEMPT SMP NOPTICPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36Tainted: [W]=WARNHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:__lock_acquire (kernel/---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] led_sysfs_enable+0x54/0x80 (P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ...Indeed, led_sysfs_enable() has to be called with the led_accesslock held.Hold the lock when calling led_sysfs_disable().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mfd: ene-kb3930: Fix a potential NULL pointer dereferenceThe off_gpios could be NULL. Add missing check in the kb3930_probe().This is similar to the issue fixed in commit b1ba8bcb2d1f("backlight: hx8357: Fix potential NULL pointer dereference").This was detected by our static analysis tool.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i3c: Add NULL pointer check in i3c_master_queue_ibi()The I3C master driver may receive an IBI from a target device that has notbeen probed yet. In such cases, the master calls `i3c_master_queue_ibi()`to queue an IBI work task, leading to "Unable to handle kernel read fromunreadable memory" and resulting in a kernel panic.Typical IBI handling flow:1. The I3C master scans target devices and probes their respective drivers.2. The target device driver calls `i3c_device_request_ibi()` to enable IBI and assigns `dev->ibi = ibi`.3. The I3C master receives an IBI from the target device and calls `i3c_master_queue_ibi()` to queue the target device driver's IBI handler task.However, since target device events are asynchronous to the I3C probesequence, step 3 may occur before step 2, causing `dev->ibi` to be `NULL`,leading to a kernel panic.Add a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessingan uninitialized `dev->ibi`, ensuring stability.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe()soc_dev_attr->revision could be NULL, thus,a pointer check is added to prevent potential NULL pointer dereference.This is similar to the fix in commit 3027e7b15b02("ice: Fix some null pointer dereference issues in ice_ptp.c").This issue is found by our static analysis tool.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: do not start chip while suspendedChecking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() canlead to a spurious tpm_chip_start() call:[35985.503771] i2c i2c-1: Transfer while suspended[35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810[35985.503802] Modules linked in:[35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G W 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f[35985.503814] Tainted: [W]=WARN[35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023[35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810[35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe <0f> 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5[35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246[35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000[35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001[35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000[35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820[35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120[35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000[35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0[35985.503855] Call Trace:[35985.503859] [35985.503863] ? __warn+0xd4/0x260[35985.503868] ? __i2c_transfer+0xbe/0x810[35985.503874] ? report_bug+0xf3/0x210[35985.503882] ? handle_bug+0x63/0xb0[35985.503887] ? exc_invalid_op+0x16/0x50[35985.503892] ? asm_exc_invalid_op+0x16/0x20[35985.503904] ? __i2c_transfer+0xbe/0x810[35985.503913] tpm_cr50_i2c_transfer_message+0x24/0xf0[35985.503920] tpm_cr50_i2c_read+0x8e/0x120[35985.503928] tpm_cr50_request_locality+0x75/0x170[35985.503935] tpm_chip_start+0x116/0x160[35985.503942] tpm_try_get_ops+0x57/0x90[35985.503948] tpm_find_get_ops+0x26/0xd0[35985.503955] tpm_get_random+0x2d/0x80Don't move forward with tpm_chip_start() inside tpm_try_get_ops(), unlessTPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL insuch a failure case.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix off-by-one error in do_splitSyzkaller detected a use-after-free issue in ext4_insert_dentry that wascaused by out-of-bounds access due to incorrect splitting in do_split.BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The following loop is located right above 'if' statement.for (i = count-1; i >= 0; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++;}'i' in this case could go down to -1, in which case sum of active entrieswouldn't exceed half the block size, but previous behaviour would also dosplit in half if sum would exceed at the very last block, which in case ofhaving too many long name files in a single block could lead toout-of-bounds access and following use-after-free.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: Fix race between unprepare and queue_bufA client driver may use mhi_unprepare_from_transfer() to quiesceincoming data during the client driver's tear down. The client drivermight also be processing data at the same time, resulting in a call tomhi_queue_buf() which will invoke mhi_gen_tre(). If mhi_gen_tre() runsafter mhi_unprepare_from_transfer() has torn down the channel, a panicwill occur due to an invalid dereference leading to a page fault.This occurs because mhi_gen_tre() does not verify the channel stateafter locking it. Fix this by having mhi_gen_tre() confirm the channelstate is valid, or return error to avoid accessing deinitialized data.[mani: added stable tag]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: Fix accessing freed irq affinity_hintIn stmmac_request_irq_multi_msi(), a pointer to the stack variablecpu_mask is passed to irq_set_affinity_hint(). This value is stored inirq_desc->affinity_hint, but once stmmac_request_irq_multi_msi()returns, the pointer becomes dangling.The affinity_hint is exposed via procfs with S_IRUGO permissions,allowing any unprivileged process to read it. Accessing this stalepointer can lead to:- a kernel oops or panic if the referenced memory has been released and unmapped, or- leakage of kernel data into userspace if the memory is re-used for other purposes.All platforms that use stmmac with PCI MSI (Intel, Loongson, etc) areaffected.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi_parser: refactor hfi packet parsing logicwords_count denotes the number of words in total payload, while datapoints to payload of various property within it. When words_countreaches last word, data can access memory beyond the total payload. Thiscan lead to OOB access. With this patch, the utility api for handlingindividual properties now returns the size of data consumed. Accordinglyremaining bytes are calculated before parsing the payload, therebyeliminates the OOB access possibilities.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi_parser: add check to avoid out of bound accessThere is a possibility that init_codecs is invoked multiple times duringmanipulated payload from video firmware. In such case, if codecs_countcan get incremented to value more than MAX_CODEC_NUM, there can be OOBaccess. Reset the count so that it always starts from beginning.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi: add check to handle incorrect queue sizeqsize represents size of shared queued between driver and videofirmware. Firmware can modify this value to an invalid large value. Insuch situation, empty_space will be bigger than the space actuallyavailable. Since new_wr_idx is not checked, so the following code willresult in an OOB write....qsize = qhdr->q_sizeif (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx)....if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB writeAdd check to ensure qsize is within the allocated size whilereading and writing packets into the queue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi: add a check to handle OOB in sfr regionsfr->buf_size is in shared memory and can be modified by malicious user.OOB write is possible when the size is made higher than actual sfr databuffer. Cap the size to allocated size for such cases.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initializationOn Mediatek devices with a system companion processor (SCP) the mtk_scpstructure has to be removed explicitly to avoid a resource leak.Free the structure in case the allocation of the firmware structure failsduring the firmware initialization.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t typeThe access to the PCI config space via pci_ops::read and pci_ops::write isa low-level hardware access. The functions can be accessed with disabledinterrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for thispurpose.A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot beacquired with disabled interrupts. The vmd_dev::cfg_lock is accessed inthe same context as the pci_lock.Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used withinterrupts disabled.This was reported as: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 Call Trace: rt_spin_lock+0x4e/0x130 vmd_pci_read+0x8d/0x100 [vmd] pci_user_read_config_byte+0x6f/0xe0 pci_read_config+0xfe/0x290 sysfs_kf_bin_read+0x68/0x90[bigeasy: reword commit message]Tested-off-by: Luis Claudio R. Goncalves [kwilczynski: commit log][bhelgaas: add back report info fromhttps://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: vlan: don't propagate flags on openWith the device instance lock, there is now a possibility of a deadlock:[ 1.211455] ============================================[ 1.211571] WARNING: possible recursive locking detected[ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 Not tainted[ 1.211823] --------------------------------------------[ 1.211936] ip/184 is trying to acquire lock:[ 1.212032] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0[ 1.212207][ 1.212207] but task is already holding lock:[ 1.212332] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0[ 1.212487][ 1.212487] other info that might help us debug this:[ 1.212626] Possible unsafe locking scenario:[ 1.212626][ 1.212751] CPU0[ 1.212815] ----[ 1.212871] lock(&dev->lock);[ 1.212944] lock(&dev->lock);[ 1.213016][ 1.213016] *** DEADLOCK ***[ 1.213016][ 1.213143] May be due to missing lock nesting notation[ 1.213143][ 1.213294] 3 locks held by ip/184:[ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0[ 1.213543] #1: ffffffff84e5fc70 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0[ 1.213727] #2: ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0[ 1.213895][ 1.213895] stack backtrace:[ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5[ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014[ 1.213994] Call Trace:[ 1.213995] [ 1.213996] dump_stack_lvl+0x8e/0xd0[ 1.214000] print_deadlock_bug+0x28b/0x2a0[ 1.214020] lock_acquire+0xea/0x2a0[ 1.214027] __mutex_lock+0xbf/0xd40[ 1.214038] dev_set_allmulti+0x4e/0xb0 # real_dev->flags & IFF_ALLMULTI[ 1.214040] vlan_dev_open+0xa5/0x170 # ndo_open on vlandev[ 1.214042] __dev_open+0x145/0x270[ 1.214046] __dev_change_flags+0xb0/0x1e0[ 1.214051] netif_change_flags+0x22/0x60 # IFF_UP vlandev[ 1.214053] dev_change_flags+0x61/0xb0 # for each device in group from dev->vlan_info[ 1.214055] vlan_device_event+0x766/0x7c0 # on netdevsim0[ 1.214058] notifier_call_chain+0x78/0x120[ 1.214062] netif_open+0x6d/0x90[ 1.214064] dev_open+0x5b/0xb0 # locks netdevsim0[ 1.214066] bond_enslave+0x64c/0x1230[ 1.214075] do_set_master+0x175/0x1e0 # on netdevsim0[ 1.214077] do_setlink+0x516/0x13b0[ 1.214094] rtnl_newlink+0xaba/0xb80[ 1.214132] rtnetlink_rcv_msg+0x440/0x490[ 1.214144] netlink_rcv_skb+0xeb/0x120[ 1.214150] netlink_unicast+0x1f9/0x320[ 1.214153] netlink_sendmsg+0x346/0x3f0[ 1.214157] __sock_sendmsg+0x86/0xb0[ 1.214160] ____sys_sendmsg+0x1c8/0x220[ 1.214164] ___sys_sendmsg+0x28f/0x2d0[ 1.214179] __x64_sys_sendmsg+0xef/0x140[ 1.214184] do_syscall_64+0xec/0x1d0[ 1.214190] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 1.214191] RIP: 0033:0x7f2d1b4a7e56Device setup: netdevsim0 (down) ^ ^ bond netdevsim1.100@netdevsim1 allmulticast=on (down)When we enslave the lower device (netdevsim0) which has a vlan, wepropagate vlan's allmuti/promisc flags during ndo_open. This causes(re)locking on of the real_dev.Propagate allmulti/promisc on flags change, not on the open. Thereis a slight semantics change that vlans that are down now propagatethe flags, but this seems unlikely to result in the real issues.Reproducer: echo 0 1 > /sys/bus/netdevsim/new_device dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*) dev=$(echo $dev_path | rev | cut -d/ -f1 | rev) ip link set dev $dev name netdevsim0 ip link set dev netdevsim0 up ip link add link netdevsim0 name netdevsim0.100 type vlan id 100 ip link set dev netdevsim0.100 allm---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/mediatek: Fix NULL pointer deference in mtk_iommu_device_groupCurrently, mtk_iommu calls during probe iommu_device_register beforethe hw_list from driver data is initialized. Since iommu probing issuefix, it leads to NULL pointer dereference in mtk_iommu_device_group whenhw_list is accessed with list_first_entry (not null safe).So, change the call order to ensure iommu_device_register is calledafter the driver data are initialized.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix UAF in decryption with multichannelAfter commit f7025d861694 ("smb: client: allocate crypto only forprimary server") and commit b0abcd65ec54 ("smb: client: fix UAF inasync decryption"), the channels started reusing AEAD TFM from primarychannel to perform synchronous decryption, but that can't done asthere could be multiple cifsd threads (one per channel) simultaneouslyaccessing it to perform decryption.This fixes the following KASAN splat when running fstest generic/249with 'vers=3.1.1,multichannel,max_channels=4,seal' against WindowsServer 2022:BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xba/0x110Read of size 8 at addr ffff8881046c18a0 by task cifsd/986CPU: 3 UID: 0 PID: 986 Comm: cifsd Not tainted 6.15.0-rc1 #1PREEMPT(voluntary)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc4104/01/2014Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x156/0x528 ? gf128mul_4k_lle+0xba/0x110 ? __virt_addr_valid+0x145/0x300 ? __phys_addr+0x46/0x90 ? gf128mul_4k_lle+0xba/0x110 kasan_report+0xdf/0x1a0 ? gf128mul_4k_lle+0xba/0x110 gf128mul_4k_lle+0xba/0x110 ghash_update+0x189/0x210 shash_ahash_update+0x295/0x370 ? __pfx_shash_ahash_update+0x10/0x10 ? __pfx_shash_ahash_update+0x10/0x10 ? __pfx_extract_iter_to_sg+0x10/0x10 ? ___kmalloc_large_node+0x10e/0x180 ? __asan_memset+0x23/0x50 crypto_ahash_update+0x3c/0xc0 gcm_hash_assoc_remain_continue+0x93/0xc0 crypt_message+0xe09/0xec0 [cifs] ? __pfx_crypt_message+0x10/0x10 [cifs] ? _raw_spin_unlock+0x23/0x40 ? __pfx_cifs_readv_from_socket+0x10/0x10 [cifs] decrypt_raw_data+0x229/0x380 [cifs] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs] ? __pfx_cifs_read_iter_from_socket+0x10/0x10 [cifs] smb3_receive_transform+0x837/0xc80 [cifs] ? __pfx_smb3_receive_transform+0x10/0x10 [cifs] ? __pfx___might_resched+0x10/0x10 ? __pfx_smb3_is_transform_hdr+0x10/0x10 [cifs] cifs_demultiplex_thread+0x692/0x1570 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? rcu_lockdep_current_cpu_online+0x62/0xb0 ? find_held_lock+0x32/0x90 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xd/0xd0 ? trace_irq_enable.constprop.0+0xa8/0xe0 ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0x1fe/0x380 ? kthread+0x10f/0x380 ? __pfx_kthread+0x10/0x10 ? local_clock_noinstr+0xd/0xd0 ? ret_from_fork+0x1b/0x60 ? local_clock+0x15/0x30 ? lock_release+0x29b/0x390 ? rcu_is_watching+0x20/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/huc: Fix fence not released on early probe errorsHuC delayed loading fence, introduced with commit 27536e03271da("drm/i915/huc: track delayed HuC load with a fence"), is registered withobject tracker early on driver probe but unregistered only from driverremove, which is not called on early probe errors. Since its memory isallocated under devres, then released anyway, it may happen to beallocated again to the fence and reused on future driver probes, resultingin kernel warnings that taint the kernel:<4> [309.731371] ------------[ cut here ]------------<3> [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915_sw_fence hint: sw_fence_dummy_notify+0x0/0x20 [i915]<4> [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debug_print_object+0x93/0xf0...<4> [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915_module_loa Tainted: G U 6.14.0-CI_DRM_16362-gf0fd77956987+ #1...<4> [309.731700] RIP: 0010:debug_print_object+0x93/0xf0...<4> [309.731728] Call Trace:<4> [309.731730] ...<4> [309.731949] __debug_object_init+0x17b/0x1c0<4> [309.731957] debug_object_init+0x34/0x50<4> [309.732126] __i915_sw_fence_init+0x34/0x60 [i915]<4> [309.732256] intel_huc_init_early+0x4b/0x1d0 [i915]<4> [309.732468] intel_uc_init_early+0x61/0x680 [i915]<4> [309.732667] intel_gt_common_init_early+0x105/0x130 [i915]<4> [309.732804] intel_root_gt_init_early+0x63/0x80 [i915]<4> [309.732938] i915_driver_probe+0x1fa/0xeb0 [i915]<4> [309.733075] i915_pci_probe+0xe6/0x220 [i915]<4> [309.733198] local_pci_probe+0x44/0xb0<4> [309.733203] pci_device_probe+0xf4/0x270<4> [309.733209] really_probe+0xee/0x3c0<4> [309.733215] __driver_probe_device+0x8c/0x180<4> [309.733219] driver_probe_device+0x24/0xd0<4> [309.733223] __driver_attach+0x10f/0x220<4> [309.733230] bus_for_each_dev+0x7d/0xe0<4> [309.733236] driver_attach+0x1e/0x30<4> [309.733239] bus_add_driver+0x151/0x290<4> [309.733244] driver_register+0x5e/0x130<4> [309.733247] __pci_register_driver+0x7d/0x90<4> [309.733251] i915_pci_register_driver+0x23/0x30 [i915]<4> [309.733413] i915_init+0x34/0x120 [i915]<4> [309.733655] do_one_initcall+0x62/0x3f0<4> [309.733667] do_init_module+0x97/0x2a0<4> [309.733671] load_module+0x25ff/0x2890<4> [309.733688] init_module_from_file+0x97/0xe0<4> [309.733701] idempotent_init_module+0x118/0x330<4> [309.733711] __x64_sys_finit_module+0x77/0x100<4> [309.733715] x64_sys_call+0x1f37/0x2650<4> [309.733719] do_syscall_64+0x91/0x180<4> [309.733763] entry_SYSCALL_64_after_hwframe+0x76/0x7e<4> [309.733792] ...<4> [309.733806] ---[ end trace 0000000000000000 ]---That scenario is most easily reproducible withigt@i915_module_load@reload-with-fault-injection.Fix the issue by moving the cleanup step to driver release path.(cherry picked from commit 795dbde92fe5c6996a02a5b579481de73035e7bf)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tls: explicitly disallow disconnectsyzbot discovered that it can disconnect a TLS socket and thenrun into all sort of unexpected corner cases. I have a vaguerecollection of Eric pointing this out to us a long time ago.Supporting disconnect is really hard, for one thing if offloadis enabled we'd need to wait for all packets to be _acked_.Disconnect is not commonly used, disallow it.The immediate problem syzbot run into is the warning in the strp,but that's just the easiest bug to trigger: WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Call Trace: tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix memory leak in tipc_link_xmitIn case the backlog transmit queue for system-importance messages is overloaded,tipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads tomemory leak and failure when a skb is allocated.This commit fixes this issue by purging the skb list before tipc_link_xmit()returns.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ublk: fix handling recovery & reissue in ublk_abort_queue()Commit 8284066946e6 ("ublk: grab request reference when the request is handledby userspace") doesn't grab request reference in case of recovery reissue.Then the request can be requeued & re-dispatch & failed when cancelinguring command.If it is one zc request, the request can be freed before io_uringreturns the zc buffer back, then cause kernel panic:[ 126.773061] BUG: kernel NULL pointer dereference, address: 00000000000000c8[ 126.773657] #PF: supervisor read access in kernel mode[ 126.774052] #PF: error_code(0x0000) - not-present page[ 126.774455] PGD 0 P4D 0[ 126.774698] Oops: Oops: 0000 [#1] SMP NOPTI[ 126.775034] CPU: 13 UID: 0 PID: 1612 Comm: kworker/u64:55 Not tainted 6.14.0_blk+ #182 PREEMPT(full)[ 126.775676] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014[ 126.776275] Workqueue: iou_exit io_ring_exit_work[ 126.776651] RIP: 0010:ublk_io_release+0x14/0x130 [ublk_drv]Fixes it by always grabbing request reference for aborting the request.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe: Fix an out-of-bounds shift when invalidating TLBWhen the size of the range invalidated is larger thanrounddown_pow_of_two(ULONG_MAX),The function macro roundup_pow_of_two(length) will hit an out-of-boundsshift [1].Use a full TLB invalidation for such cases.v2:- Use a define for the range size limit over which we use a full TLB invalidation. (Lucas)- Use a better calculation of the limit.[1]:[ 39.202421] ------------[ cut here ]------------[ 39.202657] UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13[ 39.202673] shift exponent 64 is too large for 64-bit type 'long unsigned int'[ 39.202688] CPU: 8 UID: 0 PID: 3129 Comm: xe_exec_system_ Tainted: G U 6.14.0+ #10[ 39.202690] Tainted: [U]=USER[ 39.202690] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 2001 02/01/2023[ 39.202691] Call Trace:[ 39.202692] [ 39.202695] dump_stack_lvl+0x6e/0xa0[ 39.202699] ubsan_epilogue+0x5/0x30[ 39.202701] __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6[ 39.202705] xe_gt_tlb_invalidation_range.cold+0x1d/0x3a [xe][ 39.202800] ? find_held_lock+0x2b/0x80[ 39.202803] ? mark_held_locks+0x40/0x70[ 39.202806] xe_svm_invalidate+0x459/0x700 [xe][ 39.202897] drm_gpusvm_notifier_invalidate+0x4d/0x70 [drm_gpusvm][ 39.202900] __mmu_notifier_release+0x1f5/0x270[ 39.202905] exit_mmap+0x40e/0x450[ 39.202912] __mmput+0x45/0x110[ 39.202914] exit_mm+0xc5/0x130[ 39.202916] do_exit+0x21c/0x500[ 39.202918] ? lockdep_hardirqs_on_prepare+0xdb/0x190[ 39.202920] do_group_exit+0x36/0xa0[ 39.202922] get_signal+0x8f8/0x900[ 39.202926] arch_do_signal_or_restart+0x35/0x100[ 39.202930] syscall_exit_to_user_mode+0x1fc/0x290[ 39.202932] do_syscall_64+0xa1/0x180[ 39.202934] ? do_user_addr_fault+0x59f/0x8a0[ 39.202937] ? lock_release+0xd2/0x2a0[ 39.202939] ? do_user_addr_fault+0x5a9/0x8a0[ 39.202942] ? trace_hardirqs_off+0x4b/0xc0[ 39.202944] ? clear_bhb_loop+0x25/0x80[ 39.202946] ? clear_bhb_loop+0x25/0x80[ 39.202947] ? clear_bhb_loop+0x25/0x80[ 39.202950] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 39.202952] RIP: 0033:0x7fa945e543e1[ 39.202961] Code: Unable to access opcode bytes at 0x7fa945e543b7.[ 39.202962] RSP: 002b:00007ffca8fb4170 EFLAGS: 00000293[ 39.202963] RAX: 000000000000003d RBX: 0000000000000000 RCX: 00007fa945e543e3[ 39.202964] RDX: 0000000000000000 RSI: 00007ffca8fb41ac RDI: 00000000ffffffff[ 39.202964] RBP: 00007ffca8fb4190 R08: 0000000000000000 R09: 00007fa945f600a0[ 39.202965] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000[ 39.202966] R13: 00007fa9460dd310 R14: 00007ffca8fb41ac R15: 0000000000000000[ 39.202970] [ 39.202970] ---[ end trace ]---(cherry picked from commit b88f48f86500bc0b44b4f73ac66d500a40d320ad)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/imagination: take paired job referenceFor paired jobs, have the fragment job take a reference on thegeometry job, so that the geometry job cannot be freed untilthe fragment job has finished with it.The geometry job structure is accessed when the fragment job is beingprepared by the GPU scheduler. Taking the reference prevents thegeometry job being freed until the fragment job no longer requires it.Fixes a use after free bug detected by KASAN:[ 124.256386] BUG: KASAN: slab-use-after-free in pvr_queue_prepare_job+0x108/0x868 [powervr][ 124.264893] Read of size 1 at addr ffff0000084cb960 by task kworker/u16:4/63
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/imagination: fix firmware memory leaksFree the memory used to hold the results of firmware image processingwhen the module is unloaded.Fix the related issue of the same memory being leaked if processingof the firmware image fails during module load.Ensure all firmware GEM objects are destroyed if firmware imageprocessing fails.Fixes memory leaks on powervr module unload detected by Kmemleak:unreferenced object 0xffff000042e20000 (size 94208): comm "modprobe", pid 470, jiffies 4295277154 hex dump (first 32 bytes): 02 ae 7f ed bf 45 84 00 3c 5b 1f ed 9f 45 45 05 .....E..<[...EE. d5 4f 5d 14 6c 00 3d 23 30 d0 3a 4a 66 0e 48 c8 .O].l.=#0.:Jf.H. backtrace (crc dd329dec): kmemleak_alloc+0x30/0x40 ___kmalloc_large_node+0x140/0x188 __kmalloc_large_node_noprof+0x2c/0x13c __kmalloc_noprof+0x48/0x4c0 pvr_fw_init+0xaa4/0x1f50 [powervr]unreferenced object 0xffff000042d20000 (size 20480): comm "modprobe", pid 470, jiffies 4295277154 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 09 00 00 00 0b 00 00 00 ................ 00 00 00 00 00 00 00 00 07 00 00 00 08 00 00 00 ................ backtrace (crc 395b02e3): kmemleak_alloc+0x30/0x40 ___kmalloc_large_node+0x140/0x188 __kmalloc_large_node_noprof+0x2c/0x13c __kmalloc_noprof+0x48/0x4c0 pvr_fw_init+0xb0c/0x1f50 [powervr]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: prime: fix ttm_bo_delayed_delete oopsFix an oops in ttm_bo_delayed_delete which results from dererencing adangling pointer:Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b7b: 0000 [#1] PREEMPT SMPCPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 Not tainted 6.14.0-rc4-00267-g505460b44513-dirty #216Hardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024Workqueue: ttm ttm_bo_delayed_delete [ttm]RIP: 0010:dma_resv_iter_first_unlocked+0x55/0x290Code: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 <41> 8b 44 24 10 c6 43 2c 01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8bRSP: 0018:ffffbf9383473d60 EFLAGS: 00010202RAX: 0000000000000001 RBX: ffffbf9383473d88 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffbf9383473d78 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 6b6b6b6b6b6b6b6bR13: ffffa003bbf78580 R14: ffffa003a6728040 R15: 00000000000383ccFS: 0000000000000000(0000) GS:ffffa00991c00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000758348024dd0 CR3: 000000012c259000 CR4: 0000000000f50ef0PKRU: 55555554Call Trace: ? __die_body.cold+0x19/0x26 ? die_addr+0x3d/0x70 ? exc_general_protection+0x159/0x460 ? asm_exc_general_protection+0x27/0x30 ? dma_resv_iter_first_unlocked+0x55/0x290 dma_resv_wait_timeout+0x56/0x100 ttm_bo_delayed_delete+0x69/0xb0 [ttm] process_one_work+0x217/0x5c0 worker_thread+0x1c8/0x3d0 ? apply_wqattrs_cleanup.part.0+0xc0/0xc0 kthread+0x10b/0x240 ? kthreads_online_cpu+0x140/0x140 ret_from_fork+0x40/0x70 ? kthreads_online_cpu+0x140/0x140 ret_from_fork_asm+0x11/0x20 The cause of this is:- drm_prime_gem_destroy calls dma_buf_put(dma_buf) which releases the reference to the shared dma_buf. The reference count is 0, so the dma_buf is destroyed, which in turn decrements the corresponding amdgpu_bo reference count to 0, and the amdgpu_bo is destroyed - calling drm_gem_object_release then dma_resv_fini (which destroys the reservation object), then finally freeing the amdgpu_bo.- nouveau_bo obj->bo.base.resv is now a dangling pointer to the memory formerly allocated to the amdgpu_bo.- nouveau_gem_object_del calls ttm_bo_put(&nvbo->bo) which calls ttm_bo_release, which schedules ttm_bo_delayed_delete.- ttm_bo_delayed_delete runs and dereferences the dangling resv pointer, resulting in a general protection fault.Fix this by moving the drm_prime_gem_destroy call fromnouveau_gem_object_del to nouveau_bo_del_ttm. This ensures that it willbe run after ttm_bo_delayed_delete.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm/smu11: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.(cherry picked from commit da7dc714a8f8e1c9fc33c57cd63583779a3bef71)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/cma: Fix workqueue crash in cma_netevent_work_handlerstruct rdma_cm_id has member "struct work_struct net_work"that is reused for enqueuing cma_netevent_work_handler()sonto cma_wq.Below crash[1] can occur if more than one call tocma_netevent_callback() occurs in quick succession,which further enqueues cma_netevent_work_handler()s for thesame rdma_cm_id, overwriting any previously queued work-item(s)that was just scheduled to run i.e. there is no guaranteethe queued work item may run between two successive callsto cma_netevent_callback() and the 2nd INIT_WORK would overwritethe 1st work item (for the same rdma_cm_id), despite grabbingid_table_lock during enqueue.Also drgn analysis [2] indicates the work item was likely overwritten.Fix this by moving the INIT_WORK() to __rdma_create_id(),so that it doesn't race with any existing queue_work() orits worker thread.[1] Trimmed crash stack:=============================================BUG: kernel NULL pointer dereference, address: 0000000000000008kworker/u256:6 ... 6.12.0-0...Workqueue: cma_netevent_work_handler [rdma_cm] (rdma_cm)RIP: 0010:process_one_work+0xba/0x31aCall Trace: worker_thread+0x266/0x3a0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30=============================================[2] drgn crash analysis:>>> trace = prog.crashed_thread().stack_trace()>>> trace(0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15)(1) __crash_kexec (kernel/crash_core.c:122:4)(2) panic (kernel/panic.c:399:3)(3) oops_end (arch/x86/kernel/dumpstack.c:382:3)...(8) process_one_work (kernel/workqueue.c:3168:2)(9) process_scheduled_works (kernel/workqueue.c:3310:3)(10) worker_thread (kernel/workqueue.c:3391:4)(11) kthread (kernel/kthread.c:389:9)Line workqueue.c:3168 for this kernel version is in process_one_work():3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);>>> trace[8]["work"]*(struct work_struct *)0xffff92577d0a21d8 = { .data = (atomic_long_t){ .counter = (s64)536870912, <=== Note }, .entry = (struct list_head){ .next = (struct list_head *)0xffff924d075924c0, .prev = (struct list_head *)0xffff924d075924c0, }, .func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280,}Suspicion is that pwq is NULL:>>> trace[8]["pwq"](struct pool_workqueue *)
In process_one_work(), pwq is assigned from:struct pool_workqueue *pwq = get_work_pwq(work);and get_work_pwq() is:static struct pool_workqueue *get_work_pwq(struct work_struct *work){ unsigned long data = atomic_long_read(&work->data); if (data & WORK_STRUCT_PWQ) return work_struct_pwq(data); else return NULL;}WORK_STRUCT_PWQ is 0x4:>>> print(repr(prog['WORK_STRUCT_PWQ']))Object(prog, 'enum work_flags', value=4)But work->data is 536870912 which is 0x20000000.So, get_work_pwq() returns NULL and we crash in process_one_work():3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);=============================================
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtiofs: add filesystem context source name checkIn certain scenarios, for example, during fuzz testing, the sourcename may be NULL, which could lead to a kernel panic. Therefore, anextra check for the source name should be added.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:isofs: Prevent the use of too small fidsyzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1]The handle_bytes value passed in by the reproducing program is equal to 12.In handle_to_path(), only 12 bytes of memory are allocated for the structurefile_handle->f_handle member, which causes an out-of-bounds access whenaccessing the member parent_block of the structure isofs_fid in isofs,because accessing parent_block requires at least 16 bytes of f_handle.Here, fh_len is used to indirectly confirm that the value of handle_bytesis greater than 3 before accessing parent_block.[1]BUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183Read of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466CPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0x198/0x550 mm/kasan/report.c:521 kasan_report+0xd8/0x138 mm/kasan/report.c:634 __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380 isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523 do_handle_to_path+0xa0/0x198 fs/fhandle.c:257 handle_to_path fs/fhandle.c:385 [inline] do_handle_open+0x8cc/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600Allocated by task 6466: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4294 [inline] __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306 kmalloc_noprof include/linux/slab.h:905 [inline] handle_to_path fs/fhandle.c:357 [inline] do_handle_open+0x5a4/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: cros-ec-tunnel: defer probe if parent EC is not presentWhen i2c-cros-ec-tunnel and the EC driver are built-in, the EC parentdevice will not be found, leading to NULL pointer dereference.That can also be reproduced by unbinding the controller driver and thenloading i2c-cros-ec-tunnel module (or binding the device).[ 271.991245] BUG: kernel NULL pointer dereference, address: 0000000000000058[ 271.998215] #PF: supervisor read access in kernel mode[ 272.003351] #PF: error_code(0x0000) - not-present page[ 272.008485] PGD 0 P4D 0[ 272.011022] Oops: Oops: 0000 [#1] SMP NOPTI[ 272.015207] CPU: 0 UID: 0 PID: 3859 Comm: insmod Tainted: G S 6.15.0-rc1-00004-g44722359ed83 #30 PREEMPT(full) 3c7fb39a552e7d949de2ad921a7d6588d3a4fdc5[ 272.030312] Tainted: [S]=CPU_OUT_OF_SPEC[ 272.034233] Hardware name: HP Berknip/Berknip, BIOS Google_Berknip.13434.356.0 05/17/2021[ 272.042400] RIP: 0010:ec_i2c_probe+0x2b/0x1c0 [i2c_cros_ec_tunnel][ 272.048577] Code: 1f 44 00 00 41 57 41 56 41 55 41 54 53 48 83 ec 10 65 48 8b 05 06 a0 6c e7 48 89 44 24 08 4c 8d 7f 10 48 8b 47 50 4c 8b 60 78 <49> 83 7c 24 58 00 0f 84 2f 01 00 00 48 89 fb be 30 06 00 00 4c 9[ 272.067317] RSP: 0018:ffffa32082a03940 EFLAGS: 00010282[ 272.072541] RAX: ffff969580b6a810 RBX: ffff969580b68c10 RCX: 0000000000000000[ 272.079672] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff969580b68c00[ 272.086804] RBP: 00000000fffffdfb R08: 0000000000000000 R09: 0000000000000000[ 272.093936] R10: 0000000000000000 R11: ffffffffc0600000 R12: 0000000000000000[ 272.101067] R13: ffffffffa666fbb8 R14: ffffffffc05b5528 R15: ffff969580b68c10[ 272.108198] FS: 00007b930906fc40(0000) GS:ffff969603149000(0000) knlGS:0000000000000000[ 272.116282] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 272.122024] CR2: 0000000000000058 CR3: 000000012631c000 CR4: 00000000003506f0[ 272.129155] Call Trace:[ 272.131606] [ 272.133709] ? acpi_dev_pm_attach+0xdd/0x110[ 272.137985] platform_probe+0x69/0xa0[ 272.141652] really_probe+0x152/0x310[ 272.145318] __driver_probe_device+0x77/0x110[ 272.149678] driver_probe_device+0x1e/0x190[ 272.153864] __driver_attach+0x10b/0x1e0[ 272.157790] ? driver_attach+0x20/0x20[ 272.161542] bus_for_each_dev+0x107/0x150[ 272.165553] bus_add_driver+0x15d/0x270[ 272.169392] driver_register+0x65/0x110[ 272.173232] ? cleanup_module+0xa80/0xa80 [i2c_cros_ec_tunnel 3a00532f3f4af4a9eade753f86b0f8dd4e4e5698][ 272.182617] do_one_initcall+0x110/0x350[ 272.186543] ? security_kernfs_init_security+0x49/0xd0[ 272.191682] ? __kernfs_new_node+0x1b9/0x240[ 272.195954] ? security_kernfs_init_security+0x49/0xd0[ 272.201093] ? __kernfs_new_node+0x1b9/0x240[ 272.205365] ? kernfs_link_sibling+0x105/0x130[ 272.209810] ? kernfs_next_descendant_post+0x1c/0xa0[ 272.214773] ? kernfs_activate+0x57/0x70[ 272.218699] ? kernfs_add_one+0x118/0x160[ 272.222710] ? __kernfs_create_file+0x71/0xa0[ 272.227069] ? sysfs_add_bin_file_mode_ns+0xd6/0x110[ 272.232033] ? internal_create_group+0x453/0x4a0[ 272.236651] ? __vunmap_range_noflush+0x214/0x2d0[ 272.241355] ? __free_frozen_pages+0x1dc/0x420[ 272.245799] ? free_vmap_area_noflush+0x10a/0x1c0[ 272.250505] ? load_module+0x1509/0x16f0[ 272.254431] do_init_module+0x60/0x230[ 272.258181] __se_sys_finit_module+0x27a/0x370[ 272.262627] do_syscall_64+0x6a/0xf0[ 272.266206] ? do_syscall_64+0x76/0xf0[ 272.269956] ? irqentry_exit_to_user_mode+0x79/0x90[ 272.274836] entry_SYSCALL_64_after_hwframe+0x55/0x5d[ 272.279887] RIP: 0033:0x7b9309168d39[ 272.283466] Code: 5b 41 5c 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d af 40 0c 00 f7 d8 64 89 01 8[ 272.302210] RSP: 002b:00007fff50f1a288 EFLAGS: 00000246 ORIG_RAX: 000---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ti: icss-iep: Fix possible NULL pointer dereference for perout requestThe ICSS IEP driver tracks perout and pps enable state with flags.Currently when disabling pps and perout signals during icss_iep_exit(),results in NULL pointer dereference for perout.To fix the null pointer dereference issue, the icss_iep_perout_enable_hwfunction can be modified to directly clear the IEP CMP registers whendisabling PPS or PEROUT, without referencing the ptp_perout_requeststructure, as its contents are irrelevant in this case.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: free routing table on probe failureIf complete = true in dsa_tree_setup(), it means that we are the lastswitch of the tree which is successfully probing, and we should besetting up all switches from our probe path.After "complete" becomes true, dsa_tree_setup_cpu_ports() or anysubsequent function may fail. If that happens, the entire tree setup isin limbo: the first N-1 switches have successfully finished probing(doing nothing but having allocated persistent memory in the tree'sdst->ports, and maybe dst->rtable), and switch N failed to probe, endingthe tree setup process before anything is tangible from the user's PoV.If switch N fails to probe, its memory (ports) will be freed and removedfrom dst->ports. However, the dst->rtable elements pointing to its ports,as created by dsa_link_touch(), will remain there, and will lead touse-after-free if dereferenced.If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirelypossible because that is where ds->ops->setup() is, we get a kasanreport like this:==================================================================BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350The simplest way to fix the bug is to delete the routing table in itsentirety. dsa_tree_setup_routing_table() has no problem in regeneratingit even if we deleted links between ports other than those of switch N,because dsa_link_touch() first checks whether the port pair alreadyexists in dst->rtable, allocating if not.The deletion of the routing table in its entirety already exists indsa_tree_teardown(), so refactor that into a function that can also becalled from the tree setup error path.In my analysis of the commit to blame, it is the one which addeddsa_link elements to dst->rtable. Prior to that, each switch had its ownds->rtable which is freed when the switch fails to probe. But the treeis potentially persistent memory.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: avoid unregistering devlink regions which were never registeredRussell King reports that a system with mv88e6xxx dereferences a NULLpointer when unbinding this driver:https://lore.kernel.org/netdev/Z_lRkMlTJ1KQ0kVX@shell.armlinux.org.uk/The crash seems to be in devlink_region_destroy(), which is not NULLtolerant but is given a NULL devlink global region pointer.At least on some chips, some devlink regions are conditionally registeredsince the blamed commit, see mv88e6xxx_setup_devlink_regions_global(): if (cond && !cond(chip)) continue;These are MV88E6XXX_REGION_STU and MV88E6XXX_REGION_PVT. If the chipdoes not have an STU or PVT, it should crash like this.To fix the issue, avoid unregistering those regions which are NULL, i.e.were skipped at mv88e6xxx_setup_devlink_regions_global() time.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxgb4: fix memory leak in cxgb4_init_ethtool_filters() error pathIn the for loop used to allocate the loc_array and bmap for each port, amemory leak is possible when the allocation for loc_array succeeds,but the allocation for bmap fails. This is because when the control flowgoes to the label free_eth_finfo, only the allocations starting from(i-1)th iteration are freed.Fix that by freeing the loc_array in the bmap allocation error path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btrtl: Prevent potential NULL dereferenceThe btrtl_initialize() function checks that rtl_load_file() eitherhad an error or it loaded a zero length file. However, if it loadeda zero length file then the error code is not set correctly. Itresults in an error pointer vs NULL bug, followed by a NULL pointerdereference. This was detected by Smatch:drivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to 'ERR_PTR'
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: Intel: avs: Fix null-ptr-deref in avs_component_probe()devm_kasprintf() returns NULL when memory allocation fails. Currently,avs_component_probe() does not check for this case, which results in aNULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Purge vif txq in ieee80211_do_stop()After ieee80211_do_stop() SKB from vif's txq could still be processed.Indeed another concurrent vif schedule_and_wake_txq call could causethose packets to be dequeued (see ieee80211_handle_wake_tx_queue())without checking the sdata current state.Because vif.drv_priv is now cleared in this function, this could lead todriver crash.For example in ath12k, ahvif is store in vif.drv_priv. Thus ifath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can beNULL, leading the ath12k_warn(ahvif->ah,...) call in this function totrigger the NULL deref below. Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158To avoid that, empty vif's txq at ieee80211_do_stop() so no packet couldbe dequeued after ieee80211_do_stop() (new packets cannot be queuedbecause SDATA_STATE_RUNNING is cleared at this point).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: at76c50x: fix use after free access in at76_disconnectThe memory pointed to by priv is freed at the end of at76_delete_devicefunction (using ieee80211_free_hw). But the code then accesses the udevfield of the freed object to put the USB device. This may also lead to amemory leak of the usb device. Fix this by using udev from interface.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udmabuf: fix a buf size overflow issue during udmabuf creationby casting size_limit_mb to u64 when calculate pglimit.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:misc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler registrationResolve kernel panic while accessing IRQ handler associated with thegenerated IRQ. This is done by acquiring the spinlock and storing thecurrent interrupt state before handling the interrupt request usinggeneric_handle_irq.A previous fix patch was submitted where 'generic_handle_irq' wasreplaced with 'handle_nested_irq'. However, this change also causesthe kernel panic where after determining which GPIO triggered theinterrupt and attempting to call handle_nested_irq with the mappedIRQ number, leads to a failure in locating the registered handler.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mei: vsc: Fix fortify-panic caused by invalid counted_by() usegcc 15 honors the __counted_by(len) attribute on vsc_tp_packet.buf[]and the vsc-tp.c code is using this in a wrong way. len does not containthe available size in the buffer, it contains the actual packet length*without* the crc. So as soon as vsc_tp_xfer() tries to add the crc tobuf[] the fortify-panic handler gets triggered:[ 80.842193] memcpy: detected buffer overflow: 4 byte write of buffer size 0[ 80.842243] WARNING: CPU: 4 PID: 272 at lib/string_helpers.c:1032 __fortify_report+0x45/0x50...[ 80.843175] __fortify_panic+0x9/0xb[ 80.843186] vsc_tp_xfer.cold+0x67/0x67 [mei_vsc_hw][ 80.843210] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90[ 80.843229] ? lockdep_hardirqs_on+0x7c/0x110[ 80.843250] mei_vsc_hw_start+0x98/0x120 [mei_vsc][ 80.843270] mei_reset+0x11d/0x420 [mei]The easiest fix would be to just drop the counted-by but with the exceptionof the ack buffer in vsc_tp_xfer_helper() which only contains enough roomfor the packet-header, all other uses of vsc_tp_packet always use a bufferof VSC_TP_MAX_XFER_SIZE bytes for the packet.Instead of just dropping the counted-by, split the vsc_tp_packet structdefinition into a header and a full-packet definition and use a fixedsize buf[] in the packet definition, this way fortify-source bufferoverrun checking still works when enabled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mcb: fix a double free bug in chameleon_parse_gdd()In chameleon_parse_gdd(), if mcb_device_register() fails, 'mdev'would be released in mcb_device_register() via put_device().Thus, goto 'err' label and free 'mdev' again causes a double free.Just return if mcb_device_register() fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode()With ACPI in place, gicv2m_get_fwnode() is registered with the pcisubsystem as pci_msi_get_fwnode_cb(), which may get invoked at runtimeduring a PCI host bridge probe. But, the call back is wrongly marked as__init, causing it to be freed, while being registered with the PCIsubsystem and could trigger: Unable to handle kernel paging request at virtual address ffff8000816c0400 gicv2m_get_fwnode+0x0/0x58 (P) pci_set_bus_msi_domain+0x74/0x88 pci_register_host_bridge+0x194/0x548This is easily reproducible on a Juno board with ACPI boot.Retain the function for later use.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen-netfront: handle NULL returned by xdp_convert_buff_to_frame()The function xdp_convert_buff_to_frame() may return NULL if it failsto correctly convert the XDP buffer into an XDP frame due to memoryconstraints, internal errors, or invalid data. Failing to check for NULLmay lead to a NULL pointer dereference if the result is used later inprocessing, potentially causing crashes, data corruption, or undefinedbehavior.On XDP redirect failure, the associated page must be released explicitlyif it was previously retained via get_page(). Failing to do so may resultin a memory leak, as the pages reference count is not decremented.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/eevdf: Fix se->slice being set to U64_MAX and resulting crashThere is a code path in dequeue_entities() that can set the slice of asched_entity to U64_MAX, which sometimes results in a crash.The offending case is when dequeue_entities() is called to dequeue adelayed group entity, and then the entity's parent's dequeue is delayed.In that case:1. In the if (entity_is_task(se)) else block at the beginning of dequeue_entities(), slice is set to cfs_rq_min_slice(group_cfs_rq(se)). If the entity was delayed, then it has no queued tasks, so cfs_rq_min_slice() returns U64_MAX.2. The first for_each_sched_entity() loop dequeues the entity.3. If the entity was its parent's only child, then the next iteration tries to dequeue the parent.4. If the parent's dequeue needs to be delayed, then it breaks from the first for_each_sched_entity() loop _without updating slice_.5. The second for_each_sched_entity() loop sets the parent's ->slice to the saved slice, which is still U64_MAX.This throws off subsequent calculations with potentially catastrophicresults. A manifestation we saw in production was:6. In update_entity_lag(), se->slice is used to calculate limit, which ends up as a huge negative number.7. limit is used in se->vlag = clamp(vlag, -limit, limit). Because limit is negative, vlag > limit, so se->vlag is set to the same huge negative number.8. In place_entity(), se->vlag is scaled, which overflows and results in another huge (positive or negative) number.9. The adjusted lag is subtracted from se->vruntime, which increases or decreases se->vruntime by a huge number.10. pick_eevdf() calls entity_eligible()/vruntime_eligible(), which incorrectly returns false because the vruntime is so far from the other vruntimes on the queue, causing the (vruntime - cfs_rq->min_vruntime) * load calulation to overflow.11. Nothing appears to be eligible, so pick_eevdf() returns NULL.12. pick_next_entity() tries to dereference the return value of pick_eevdf() and crashes.Dumping the cfs_rq states from the core dumps with drgn showed tell-talehuge vruntime ranges and bogus vlag values, and I also traced se->slicebeing set to U64_MAX on live systems (which was usually "benign" sincethe rest of the runqueue needed to be in a particular state to crash).Fix it in dequeue_entities() by always setting slice from the firstnon-empty cfs_rq.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix NULL pointer dereference in tipc_mon_reinit_self()syzbot reported:tipc: Node number set to 1055423674Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Workqueue: events tipc_net_finalize_workRIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719...RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cbaRDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 ...RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719...RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cbaRDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400There is a racing condition between workqueue created when enablingbearer and another thread created when disabling bearer right afterthat as follow:enabling_bearer | disabling_bearer--------------- | ----------------tipc_disc_timeout() |{ | bearer_disable() ... | { schedule_work(&tn->work); | tipc_mon_delete() ... | {} | ... | write_lock_bh(&mon->lock); | mon->self = NULL; | write_unlock_bh(&mon->lock); | ... | }tipc_net_finalize_work() | }{ | ... | tipc_net_finalize() | { | ... | tipc_mon_reinit_self() | { | ... | write_lock_bh(&mon->lock); | mon->self->addr = tipc_own_addr(net); | write_unlock_bh(&mon->lock); | ... ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Add NULL check in ufshcd_mcq_compl_pending_transfer()Add a NULL check for the returned hwq pointer by ufshcd_mcq_req_to_hwq().This is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fixufshcd_abort_one racing issue").
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: return EIO on RAID1 block group write pointer mismatchThere was a bug report about a NULL pointer dereference in__btrfs_add_free_space_zoned() that ultimately happens because aconversion from the default metadata profile DUP to a RAID1 profile on twodisks.The stack trace has the following signature: BTRFS error (device sdc): zoned: write pointer offset mismatch of zones in raid1 profile BUG: kernel NULL pointer dereference, address: 0000000000000058 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:__btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 RSP: 0018:ffffa236b6f3f6d0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff96c8132f3400 RCX: 0000000000000001 RDX: 0000000010000000 RSI: 0000000000000000 RDI: ffff96c8132f3410 RBP: 0000000010000000 R08: 0000000000000003 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000000 R13: ffff96c758f65a40 R14: 0000000000000001 R15: 000011aac0000000 FS: 00007fdab1cb2900(0000) GS:ffff96e60ca00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000058 CR3: 00000001a05ae000 CR4: 0000000000350ef0 Call Trace: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15c/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 btrfs_add_free_space_async_trimmed+0x34/0x40 btrfs_add_new_free_space+0x107/0x120 btrfs_make_block_group+0x104/0x2b0 btrfs_create_chunk+0x977/0xf20 btrfs_chunk_alloc+0x174/0x510 ? srso_return_thunk+0x5/0x5f btrfs_inc_block_group_ro+0x1b1/0x230 btrfs_relocate_block_group+0x9e/0x410 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x8ac/0x12b0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? __kmalloc_cache_noprof+0x14c/0x3e0 btrfs_ioctl+0x2686/0x2a80 ? srso_return_thunk+0x5/0x5f ? ioctl_has_perm.constprop.0.isra.0+0xd2/0x120 __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x82/0x160 ? srso_return_thunk+0x5/0x5f ? __memcg_slab_free_hook+0x11a/0x170 ? srso_return_thunk+0x5/0x5f ? kmem_cache_free+0x3f0/0x450 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? sysfs_emit+0xaf/0xc0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? seq_read_iter+0x207/0x460 ? srso_return_thunk+0x5/0x5f ? vfs_read+0x29c/0x370 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? srso_return_thunk+0x5/0x5f ? exc_page_fault+0x7e/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdab1e0ca6d RSP: 002b:00007ffeb2b60c80 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdab1e0ca6d RDX: 00007ffeb2b60d80 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 00007ffeb2b60cd0 R08: 0000000000000000 R09: 0000000000000013 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffeb2b6343b R14: 00007ffeb2b60d80 R15: 0000000000000001 CR2: 0000000000000058 ---[ end trace 0000000000000000 ]---The 1st line is the most interesting here: BTRFS error (device sdc): zoned: write pointer offset mismatch of zones in raid1 profileWhen a RAID1 block-group is created and a write pointer mismatch betweenthe disks in the RAID set is detected, btrfs sets the alloc_offset to thelength of the block group marking it as full. Afterwards the code expectsthat a balance operation will evacuate the data in this block-group andrepair the problems.But before this is possible, the new space of this block-group will beaccounted in the free space cache. But in __btrfs_---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: mcq: Add NULL check in ufshcd_mcq_abort()A race can occur between the MCQ completion path and the abort handler:once a request completes, __blk_mq_free_request() sets rq->mq_hctx toNULL, meaning the subsequent ufshcd_mcq_req_to_hwq() call inufshcd_mcq_abort() can return a NULL pointer. If this NULL pointer isdereferenced, the kernel will crash.Add a NULL check for the returned hwq pointer. If hwq is NULL, log anerror and return FAILED, preventing a potential NULL-pointerdereference. As suggested by Bart, the ufshcd_cmd_inflight() check isremoved.This is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fixufshcd_abort_one racing issue").This is found by our static analysis tool KNighter.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()cpufreq_cpu_get_raw() can return NULL when the target CPU is not presentin the policy->cpus mask. scpi_cpufreq_get_rate() does not check forthis case, which results in a NULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate()cpufreq_cpu_get_raw() can return NULL when the target CPU is not presentin the policy->cpus mask. scmi_cpufreq_get_rate() does not check forthis case, which results in a NULL pointer dereference.Add NULL check after cpufreq_cpu_get_raw() to prevent this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: apple-soc: Fix null-ptr-deref in apple_soc_cpufreq_get_rate()cpufreq_cpu_get_raw() can return NULL when the target CPU is not presentin the policy->cpus mask. apple_soc_cpufreq_get_rate() does not checkfor this case, which results in a NULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry readsFix niu_try_msix() to not cause a fatal trap on sparc systems.Set PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev towork around a bug in the hardware or firmware.For each vector entry in the msix table, niu chips will cause a fataltrap if any registers in that entry are read before that entries'ENTRY_DATA register is written to. Testing indicates writes to otherregisters are not sufficient to prevent the fatal trap, however the valuedoes not appear to matter. This only needs to happen once after power up,so simply rebooting into a kernel lacking this fix will NOT cause thetrap.NON-RESUMABLE ERROR: Reporting on cpu 64NON-RESUMABLE ERROR: TPC [0x00000000005f6900] NON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffffNON-RESUMABLE ERROR: 0000000800000000:0000000000000000:0000000000000000:0000000000000000]NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff]NON-RESUMABLE ERROR: type [precise nonresumable]NON-RESUMABLE ERROR: attrs [0x02000080] < ASI sp-faulted priv >NON-RESUMABLE ERROR: raddr [0xffffffffffffffff]NON-RESUMABLE ERROR: insn effective address [0x000000c50020000c]NON-RESUMABLE ERROR: size [0x8]NON-RESUMABLE ERROR: asi [0x00]CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63Workqueue: events work_for_cpu_fnTSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 Not taintedTPC: g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128RPC: <__pci_enable_msix_range+0x3cc/0x460>l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000di4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0I7: Call Trace:[<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu][<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu][<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu][<00000000005ef3e4>] local_pci_probe+0x28/0x74[<0000000000469240>] work_for_cpu_fn+0x8/0x1c[<000000000046b008>] process_scheduled_works+0x144/0x210[<000000000046b518>] worker_thread+0x13c/0x1c0[<00000000004710e0>] kthread+0xb8/0xc8[<00000000004060c8>] ret_from_fork+0x1c/0x2c[<0000000000000000>] 0x0Kernel panic - not syncing: Non-resumable error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Fix reference leak in pci_register_host_bridge()If device_register() fails, call put_device() to give up the reference toavoid a memory leak, per the comment at device_register().Found by code review.[bhelgaas: squash Dan Carpenter's double free fix fromhttps://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: brcmnand: fix PM resume warningFixed warning on PM resume as shown below caused due to uninitializedstruct nand_operation that checks chip select field :WARN_ON(op->cs >= nanddev_ntargets(&chip->base)[ 14.588522] ------------[ cut here ]------------[ 14.588529] WARNING: CPU: 0 PID: 1392 at drivers/mtd/nand/raw/internals.h:139 nand_reset_op+0x1e0/0x1f8[ 14.588553] Modules linked in: bdc udc_core[ 14.588579] CPU: 0 UID: 0 PID: 1392 Comm: rtcwake Tainted: G W 6.14.0-rc4-g5394eea10651 #16[ 14.588590] Tainted: [W]=WARN[ 14.588593] Hardware name: Broadcom STB (Flattened Device Tree)[ 14.588598] Call trace:[ 14.588604] dump_backtrace from show_stack+0x18/0x1c[ 14.588622] r7:00000009 r6:0000008b r5:60000153 r4:c0fa558c[ 14.588625] show_stack from dump_stack_lvl+0x70/0x7c[ 14.588639] dump_stack_lvl from dump_stack+0x18/0x1c[ 14.588653] r5:c08d40b0 r4:c1003cb0[ 14.588656] dump_stack from __warn+0x84/0xe4[ 14.588668] __warn from warn_slowpath_fmt+0x18c/0x194[ 14.588678] r7:c08d40b0 r6:c1003cb0 r5:00000000 r4:00000000[ 14.588681] warn_slowpath_fmt from nand_reset_op+0x1e0/0x1f8[ 14.588695] r8:70c40dff r7:89705f41 r6:36b4a597 r5:c26c9444 r4:c26b0048[ 14.588697] nand_reset_op from brcmnand_resume+0x13c/0x150[ 14.588714] r9:00000000 r8:00000000 r7:c24f8010 r6:c228a3f8 r5:c26c94bc r4:c26b0040[ 14.588717] brcmnand_resume from platform_pm_resume+0x34/0x54[ 14.588735] r5:00000010 r4:c0840a50[ 14.588738] platform_pm_resume from dpm_run_callback+0x5c/0x14c[ 14.588757] dpm_run_callback from device_resume+0xc0/0x324[ 14.588776] r9:c24f8054 r8:c24f80a0 r7:00000000 r6:00000000 r5:00000010 r4:c24f8010[ 14.588779] device_resume from dpm_resume+0x130/0x160[ 14.588799] r9:c22539e4 r8:00000010 r7:c22bebb0 r6:c24f8010 r5:c22539dc r4:c22539b0[ 14.588802] dpm_resume from dpm_resume_end+0x14/0x20[ 14.588822] r10:c2204e40 r9:00000000 r8:c228a3fc r7:00000000 r6:00000003 r5:c228a414[ 14.588826] r4:00000010[ 14.588828] dpm_resume_end from suspend_devices_and_enter+0x274/0x6f8[ 14.588848] r5:c228a414 r4:00000000[ 14.588851] suspend_devices_and_enter from pm_suspend+0x228/0x2bc[ 14.588868] r10:c3502910 r9:c3501f40 r8:00000004 r7:c228a438 r6:c0f95e18 r5:00000000[ 14.588871] r4:00000003[ 14.588874] pm_suspend from state_store+0x74/0xd0[ 14.588889] r7:c228a438 r6:c0f934c8 r5:00000003 r4:00000003[ 14.588892] state_store from kobj_attr_store+0x1c/0x28[ 14.588913] r9:00000000 r8:00000000 r7:f09f9f08 r6:00000004 r5:c3502900 r4:c0283250[ 14.588916] kobj_attr_store from sysfs_kf_write+0x40/0x4c[ 14.588936] r5:c3502900 r4:c0d92a48[ 14.588939] sysfs_kf_write from kernfs_fop_write_iter+0x104/0x1f0[ 14.588956] r5:c3502900 r4:c3501f40[ 14.588960] kernfs_fop_write_iter from vfs_write+0x250/0x420[ 14.588980] r10:c0e14b48 r9:00000000 r8:c25f5780 r7:00443398 r6:f09f9f68 r5:c34f7f00[ 14.588983] r4:c042a88c[ 14.588987] vfs_write from ksys_write+0x74/0xe4[ 14.589005] r10:00000004 r9:c25f5780 r8:c02002fA0 r7:00000000 r6:00000000 r5:c34f7f00[ 14.589008] r4:c34f7f00[ 14.589011] ksys_write from sys_write+0x10/0x14[ 14.589029] r7:00000004 r6:004421c0 r5:00443398 r4:00000004[ 14.589032] sys_write from ret_fast_syscall+0x0/0x5c[ 14.589044] Exception stack(0xf09f9fa8 to 0xf09f9ff0)[ 14.589050] 9fa0: 00000004 00443398 00000004 00443398 00000004 00000001[ 14.589056] 9fc0: 00000004 00443398 004421c0 00000004 b6ecbd58 00000008 bebfbc38 0043eb78[ 14.589062] 9fe0: 00440eb0 bebfbaf8 b6de18a0 b6e579e8[ 14.589065] ---[ end trace 0000000000000000 ]---The fix uses the higher level nand_reset(chip, chipnr); where chipnr = 0, whendoing PM resume operation in compliance with the controller support for singledie nand chip. Switching from nand_reset_op() to nan---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: fsl-qspi: use devm function instead of driver removeDriver use devm APIs to manage clk/irq/resources and register the spicontroller, but the legacy remove function will be called first duringdevice detach and trigger kernel panic. Drop the remove function and usedevm_add_action_or_reset() for driver cleanup to ensure the releasesequence.Trigger kernel panic on i.MX8MQ byecho 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: pciehp: Avoid unnecessary device replacement checkHot-removal of nested PCI hotplug ports suffers from a long-standing racecondition which can lead to a deadlock: A parent hotplug port acquirespci_lock_rescan_remove(), then waits for pciehp to unbind from a childhotplug port. Meanwhile that child hotplug port tries to acquirepci_lock_rescan_remove() as well in order to remove its own children.The deadlock only occurs if the parent acquires pci_lock_rescan_remove()first, not if the child happens to acquire it first.Several workarounds to avoid the issue have been proposed and discardedover the years, e.g.:https://lore.kernel.org/r/4c882e25194ba8282b78fe963fec8faae7cf23eb.1529173804.git.lukas@wunner.de/A proper fix is being worked on, but needs more time as it is nontrivialand necessarily intrusive.Recent commit 9d573d19547b ("PCI: pciehp: Detect device replacement duringsystem sleep") provokes more frequent occurrence of the deadlock whenremoving more than one Thunderbolt device during system sleep. The commitsought to detect device replacement, but also triggered on device removal.Differentiating reliably between replacement and removal is impossiblebecause pci_get_dsn() returns 0 both if the device was removed, as well asif it was replaced with one lacking a Device Serial Number.Avoid the more frequent occurrence of the deadlock by checking whether thehotplug port itself was hot-removed. If so, there's no sense in checkingwhether its child device was replaced.This works because the ->resume_noirq() callback is invoked in top-downorder for the entire hierarchy: A parent hotplug port detecting devicereplacement (or removal) marks all children as removed usingpci_dev_set_disconnected() and a child hotplug port can then reliablydetect being removed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: avoid NULL pointer dereference in dbg callcifs_server_dbg() implies server to be non-NULL somove call under condition to avoid NULL pointer dereference.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: mops: Do not dereference src reg for a set operationThe source register is not used for SET* and reading it can result ina UBSAN out-of-bounds array access error, specifically when the MOPSexception is taken from a SET* sequence with XZR (reg 31) as thesource. Architecturally this is the only case where a src/dst/sizefield in the ESR can be reported as 31.Prior to 2de451a329cf662b the code in do_el0_mops() was benign as theuse of pt_regs_read_reg() prevented the out-of-bounds access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:accel/ivpu: Fix deadlock in ivpu_ms_cleanup()Fix deadlock in ivpu_ms_cleanup() by preventing runtime resume afterfile_priv->ms_lock is acquired.During a failure in runtime resume, a cold boot is executed, whichcalls ivpu_ms_cleanup_all(). This function calls ivpu_ms_cleanup()that acquires file_priv->ms_lock and causes the deadlock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:accel/ivpu: Fix PM related deadlocks in MS IOCTLsPrevent runtime resume/suspend while MS IOCTLs are in progress.Failed suspend will call ivpu_ms_cleanup() that would try to acquirefile_priv->ms_lock, which is already held by the IOCTLs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create()Add error handling to propagate amdgpu_cgs_create_device() failuresto the caller. When amdgpu_cgs_create_device() fails, release hwmgrand return -ENOMEM to prevent null pointer dereference.[v1]->[v2]: Change error code from -EINVAL to -ENOMEM. Free hwmgr.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: debugfs hang_hws skip GPU with MESdebugfs hang_hws is used by GPU reset test with HWS, for MES this crashthe kernel with NULL pointer access because dqm->packet_mgr is not setupfor MES path.Skip GPU with MES for now, MES hang_hws debugfs interface will besupported later.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sfc: fix NULL dereferences in ef100_process_design_param()Since cited commit, ef100_probe_main() and hence also ef100_check_design_params() run before efx->net_dev is created; consequently, we cannot netif_set_tso_max_size() or _segs() at this point.Move those netif calls to ef100_probe_netdev(), and also replace netif_err within the design params code with pci_err.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: pidff: Fix null pointer dereference in pidff_find_fieldsThis function triggered a null pointer dereference if used to search fora report that isn't implemented on the device. This happened both foroptional and required reports alike.The same logic was applied to pidff_find_special_field and althoughpidff_init_fields should return an error earlier if one of the requiredreports is missing, future modifications could change this logic andresurface this possible null pointer dereference again.LKML bug report:https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ovl: don't allow datadir onlyIn theory overlayfs could support upper layer directly referring to a datalayer, but there's no current use case for this.Originally, when data-only layers were introduced, this wasn't allowed,only introduced by the "datadir+" feature, but without actually handlingthis case, resulting in an Oops.Fix by disallowing datadir without lowerdir.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: clean up FDB, MDB, VLAN entries on unbindAs explained in many places such as commit b117e1e8a86d ("net: dsa:delete dsa_legacy_fdb_add and dsa_legacy_fdb_del"), DSA is written giventhe assumption that higher layers have balanced additions/deletions.As such, it only makes sense to be extremely vocal when thoseassumptions are violated and the driver unbinds with entries stillpresent.But Ido Schimmel points out a very simple situation where that is wrong:https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/(also briefly discussed by me in the aforementioned commit).Basically, while the bridge bypass operations are not something that DSAexplicitly documents, and for the majority of DSA drivers this APIsimply causes them to go to promiscuous mode, that isn't the case forall drivers. Some have the necessary requirements for bridge bypassoperations to do something useful - see dsa_switch_supports_uc_filtering().Although in tools/testing/selftests/net/forwarding/local_termination.sh,we made an effort to popularize better mechanisms to manage addressfilters on DSA interfaces from user space - namely macvlan for unicast,and setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, thefact is that 'bridge fdb add ... self static local' also exists askernel UAPI, and might be useful to someone, even if only for a quickhack.It seems counter-productive to block that path by implementing shim.ndo_fdb_add and .ndo_fdb_del operations which just return -EOPNOTSUPPin order to prevent the ndo_dflt_fdb_add() and ndo_dflt_fdb_del() fromrunning, although we could do that.Accepting that cleanup is necessary seems to be the only option.Especially since we appear to be coming back at this from a differentangle as well. Russell King is noticing that the WARN_ON() triggers evenfor VLANs:https://lore.kernel.org/netdev/Z_li8Bj8bD4-BYKQ@shell.armlinux.org.uk/What happens in the bug report above is that dsa_port_do_vlan_del() fails,then the VLAN entry lingers on, and then we warn on unbind and leak it.This is not a straight revert of the blamed commit, but we now add aninformational print to the kernel log (to still have a way to seethat bugs exist), and some extra comments gathered from past years'experience, to justify the logic.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupportedRussell King reports that on the ZII dev rev B, deleting a bridge VLANfrom a user port fails with -ENOENT:https://lore.kernel.org/netdev/Z_lQXNP0s5-IiJzd@shell.armlinux.org.uk/This comes from mv88e6xxx_port_vlan_leave() -> mv88e6xxx_mst_put(),which tries to find an MST entry in &chip->msts associated with the SID,but fails and returns -ENOENT as such.But we know that this chip does not support MST at all, so that is notsurprising. The question is why does the guard in mv88e6xxx_mst_put()not exit early: if (!sid) return 0;And the answer seems to be simple: the sid comes from vlan.sid whichsupposedly was previously populated by mv88e6xxx_vtu_get().But some chip->info->ops->vtu_getnext() implementations do not populatevlan.sid, for example see mv88e6185_g1_vtu_getnext(). In that case,later in mv88e6xxx_port_vlan_leave() we are using a garbage sid which isjust residual stack memory.Testing for sid == 0 covers all cases of a non-bridge VLAN or a bridgeVLAN mapped to the default MSTI. For some chips, SID 0 is valid andinstalled by mv88e6xxx_stu_setup(). A chip which does not support theSTU would implicitly only support mapping all VLANs to the default MSTI,so although SID 0 is not valid, it would be sufficient, if we were tozero-initialize the vlan structure, to fix the bug, due to thecoincidence that a test for vlan.sid == 0 already exists and leads tothe same (correct) behavior.Another option which would be sufficient would be to add a test formv88e6xxx_has_stu() inside mv88e6xxx_mst_put(), symmetric to the onewhich already exists in mv88e6xxx_mst_get(). But that placement meansthe caller will have to dereference vlan.sid, which means it will accessuninitialized memory, which is not nice even if it ignores it later.So we end up making both modifications, in order to not rely just on thesid == 0 coincidence, but also to avoid having uninitialized structurefields which might get temporarily accessed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Silence oversized kvmalloc() warningsyzkaller triggered an oversized kvmalloc() warning.Silence it by adding __GFP_NOWARN.syzkaller log: WARNING: CPU: 7 PID: 518 at mm/util.c:665 __kvmalloc_node_noprof+0x175/0x180 CPU: 7 UID: 0 PID: 518 Comm: c_repro Not tainted 6.11.0-rc6+ #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__kvmalloc_node_noprof+0x175/0x180 RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246 RAX: 0000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002 RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000 R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 0000000000000000 R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000 FS: 00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ib_umem_odp_get+0x1f6/0x390 mlx5_ib_reg_user_mr+0x1e8/0x450 ib_uverbs_reg_mr+0x28b/0x440 ib_uverbs_write+0x7d3/0xa30 vfs_write+0x1ac/0x6c0 ksys_write+0x134/0x170 ? __sanitizer_cov_trace_pc+0x1c/0x50 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe: Use local fence in error path of xe_migrate_clearThe intent of the error path in xe_migrate_clear is to wait on locallygenerated fence and then return. The code is waiting on m->fence whichcould be the local fence but this is only stable under the job mutexleading to a possible UAF. Fix code to wait on local fence.(cherry picked from commit 762b7e95362170b3e13a8704f38d5e47eca4ba74)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: txgbe: fix memory leak in txgbe_probe() error pathWhen txgbe_sw_init() is called, memory is allocated for wx->rss_keyin wx_init_rss_key(). However, in txgbe_probe() function, the subsequenterror paths after txgbe_sw_init() don't free the rss_key. Fix that byfreeing it in error path along with wx->mac_table.Also change the label to which execution jumps when txgbe_sw_init()fails, because otherwise, it could lead to a double free for rss_key,when the mac_table allocation fails in wx_sw_init().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eth: bnxt: fix missing ring index trim on error pathCommit under Fixes converted tx_prod to be free running but missedmasking it on the Tx error path. This crashes on error conditions,for example when DMA mapping fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ngbe: fix memory leak in ngbe_probe() error pathWhen ngbe_sw_init() is called, memory is allocated for wx->rss_keyin wx_init_rss_key(). However, in ngbe_probe() function, the subsequenterror paths after ngbe_sw_init() don't free the rss_key. Fix that byfreeing it in error path along with wx->mac_table.Also change the label to which execution jumps when ngbe_sw_init()fails, because otherwise, it could lead to a double free for rss_key,when the mac_table allocation fails in wx_sw_init().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igc: fix PTM cycle trigger logicWriting to clear the PTM status 'valid' bit while the PTM cycle istriggered results in unreliable PTM operation. To fix this, clear thePTM 'trigger' and status after each PTM transaction.The issue can be reproduced with the following:$ sudo phc2sys -R 1000 -O 0 -i tsn0 -mNote: 1000 Hz (-R 1000) is unrealistically large, but provides a way toquickly reproduce the issue.PHC2SYS exits with:"ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction failsThis patch also fixes a hang in igc_probe() when loading the igcdriver in the kdump kernel on systems supporting PTM.The igc driver running in the base kernel enables PTM trigger inigc_probe(). Therefore the driver is always in PTM trigger mode,except in brief periods when manually triggering a PTM cycle.When a crash occurs, the NIC is reset while PTM trigger is enabled.Due to a hardware problem, the NIC is subsequently in a bad busmasterstate and doesn't handle register reads/writes. When runningigc_probe() in the kdump kernel, the first register access to a NICregister hangs driver probing and ultimately breaks kdump.With this patch, igc has PTM trigger disabled most of the time,and the trigger is only enabled for very brief (10 - 100 us) periodswhen manually triggering a PTM cycle. Chances that a crash occursduring a PTM trigger are not 0, but extremely reduced.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:9p/net: fix improper handling of bogus negative read/write repliesIn p9_client_write() and p9_client_read_once(), if the serverincorrectly replies with success but a negative write/read count then wewould consider written (negative) <= rsize (positive) because bothvariables were signed.Make variables unsigned to avoid this problem.The reproducer linked below now fails with the following error insteadof a null pointer deref:9pnet: bogus RWRITE count (4294967295 > 3)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev()The variable d->name, returned by devm_kasprintf(), could be NULL.A pointer check is added to prevent potential NULL pointer dereference.This is similar to the fix in commit 3027e7b15b02("ice: Fix some null pointer dereference issues in ice_ptp.c").This issue is found by our static analysis tool
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pds_core: make wait_context part of q_infoMake the wait_context a full part of the q_info struct ratherthan a stack variable that goes away after pdsc_adminq_post()is done so that the context is still available after the waitloop has given up.There was a case where a slow development firmware causedthe adminq request to time out, but then later the FW finallyfinished the request and sent the interrupt. The handler triedto complete_all() the completion context that had been createdon the stack in pdsc_adminq_post() but no longer existed.This caused bad pointer usage, kernel crashes, and much wailingand gnashing of teeth.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL resultIf the FW doesn't support the PDS_CORE_CMD_FW_CONTROL commandthe driver might at the least print garbage and at the worstcrash when the user runs the "devlink dev info" devlink command.This happens because the stack variable fw_list is not 0initialized which results in fw_list.num_fw_slots being agarbage value from the stack. Then the driver tries to accessfw_list.fw_names[i] with i >= ARRAY_SIZE and runs off the endof the array.Fix this by initializing the fw_list and by not failingcompletely if the devcmd fails because other useful informationis printed via devlink dev info even if the devcmd fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix null-ptr-deref in mlx5_create_{inner_,}ttc_table()Add NULL check for mlx5_get_flow_namespace() returns inmlx5_create_inner_ttc_table() and mlx5_create_ttc_table() to preventNULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr()As mentioned in the commit baeb705fd6a7 ("ice: always check VF VSIpointer values"), we need to perform a null pointer check on the returnvalue of ice_get_vf_vsi() before using it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: qfq: Fix double list add in class with netem as child qdiscAs described in Gerrard's report [1], there are use cases where a netemchild qdisc will make the parent qdisc's enqueue callback reentrant.In the case of qfq, there won't be a UAF, but the code will add the sameclassifier to the list twice, which will cause memory corruption.This patch checks whether the class was already added to the agg->activelist (cl_is_active) before doing the addition to cater for the reentrantcase.[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: ets: Fix double list add in class with netem as child qdiscAs described in Gerrard's report [1], there are use cases where a netemchild qdisc will make the parent qdisc's enqueue callback reentrant.In the case of ets, there won't be a UAF, but the code will add the sameclassifier to the list twice, which will cause memory corruption.In addition to checking for qlen being zero, this patch checks whetherthe class was already added to the active_list (cl_is_active) beforedoing the addition to cater for the reentrant case.[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: drr: Fix double list add in class with netem as child qdiscAs described in Gerrard's report [1], there are use cases where a netemchild qdisc will make the parent qdisc's enqueue callback reentrant.In the case of drr, there won't be a UAF, but the code will add the sameclassifier to the list twice, which will cause memory corruption.In addition to checking for qlen being zero, this patch checks whether theclass was already added to the active_list (cl_is_active) before addingto the list to cover for the reentrant case.[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: adjust subpage bit start based on sectorsizeWhen running machines with 64k page size and a 16k nodesize we startedseeing tree log corruption in production. This turned out to be becausewe were not writing out dirty blocks sometimes, so this in fact affectsall metadata writes.When writing out a subpage EB we scan the subpage bitmap for a dirtyrange. If the range isn't dirty we do bit_start++;to move onto the next bit. The problem is the bitmap is based on thenumber of sectors that an EB has. So in this case, we have a 64kpagesize, 16k nodesize, but a 4k sectorsize. This means our bitmap is 4bits for every node. With a 64k page size we end up with 4 nodes perpage.To make this easier this is how everything looks[0 16k 32k 48k ] logical address[0 4 8 12 ] radix tree offset[ 64k page ] folio[ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers[ | | | | | | | | | | | | | | | | ] bitmapNow we use all of our addressing based on fs_info->sectorsize_bits, soas you can see the above our 16k eb->start turns into radix entry 4.When we find a dirty range for our eb, we correctly do bit_start +=sectors_per_node, because if we start at bit 0, the next bit for thenext eb is 4, to correspond to eb->start 16k.However if our range is clean, we will do bit_start++, which will nowput us offset from our radix tree entries.In our case, assume that the first time we check the bitmap the block isnot dirty, we increment bit_start so now it == 1, and then we looparound and check again. This time it is dirty, and we go to find thatstart using the following equation start = folio_start + bit_start * fs_info->sectorsize;so in the case above, eb->start 0 is now dirty, and we calculate startas 0 + 1 * fs_info->sectorsize = 4096 4096 >> 12 = 1Now we're looking up the radix tree for 1, and we won't find an eb.What's worse is now we're using bit_start == 1, so we do bit_start +=sectors_per_node, which is now 5. If that eb is dirty we will run intothe same thing, we will look at an offset that is not populated in theradix tree, and now we're skipping the writeout of dirty extent buffers.The best fix for this is to not use sectorsize_bits to address nodes,but that's a larger change. Since this is a fs corruption problem fixit simply by always using sectors_per_node to increment the start bit.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: simple-card-utils: Fix pointer check in graph_util_parse_link_directionActually check if the passed pointers are valid, before writing to them.This also fixes a USBAN warning:UBSAN: invalid-load in ../sound/soc/fsl/imx-card.c:687:25load of value 255 is not a valid value for type '_Bool'This is because playback_only is uninitialized and is not written to, asthe playback-only property is absent.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: mtk_eth_soc: fix SER panic with 4GB+ RAMIf the mtk_poll_rx() function detects the MTK_RESETTING flag, it willjump to release_desc and refill the high word of the SDP on the 4GB RFB.Subsequently, mtk_rx_clean will process an incorrect SDP, leading to apanic.Add patch from MediaTek's SDK to resolve this.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU's value.When generating the MSR_IA32_PEBS_ENABLE value that will be loaded onVM-Entry to a KVM guest, mask the value with the vCPU's desired PEBS_ENABLEvalue. Consulting only the host kernel's host vs. guest masks results inrunning the guest with PEBS enabled even when the guest doesn't want to usePEBS. Because KVM uses perf events to proxy the guest virtual PMU, simplylooking at exclude_host can't differentiate between events created by hostuserspace, and events created by KVM on behalf of the guest.Running the guest with PEBS unexpectedly enabled typically manifests ascrashes due to a near-infinite stream of #PFs. E.g. if the guest hasn'twritten MSR_IA32_DS_AREA, the CPU will hit page faults on address '0' whentrying to record PEBS events.The issue is most easily reproduced by running `perf kvm top` from beforecommit 7b100989b4f6 ("perf evlist: Remove __evlist__add_default") (afterwhich, `perf kvm top` effectively stopped using PEBS). The userspace sideof perf creates a guest-only PEBS event, which intel_guest_get_msrs()misconstrues a guest-*owned* PEBS event.Arguably, this is a userspace bug, as enabling PEBS on guest-only eventssimply cannot work, and userspace can kill VMs in many other ways (thereis no danger to the host). However, even if this is considered to be baduserspace behavior, there's zero downside to perf/KVM restricting PEBS toguest-owned events.Note, commit 854250329c02 ("KVM: x86/pmu: Disable guest PEBS temporarilyin two rare situations") fixed the case where host userspace is profilingKVM *and* userspace, but missed the case where userspace is profiling onlyKVM.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()If dib8000_set_dds()'s call to dib8000_read32() returns zero, the resultis a divide-by-zero. Prevent that from happening.Fixes the following warning with an UBSAN kernel: drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Verify event formats that have "%*p.."The trace event verifier checks the formats of trace events to make surethat they do not point at memory that is not in the trace event itself orin data that will never be freed. If an event references data that wasallocated when the event triggered and that same data is freed before theevent is read, then the kernel can crash by reading freed memory.The verifier runs at boot up (or module load) and scans the print formatsof the events and checks their arguments to make sure that dereferencedpointers are safe. If the format uses "%*p.." the verifier will ignore it,and that could be dangerous. Cover this case as well.Also add to the sample code a use case of "%*pbl".
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libbpf: Fix accessing BTF.ext core_relo headerUpdate btf_ext_parse_info() to ensure the core_relo header is presentbefore reading its fields. This avoids a potential buffer read overflowreported by the OSS Fuzz project.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Add cond_resched() to ftrace_graph_set_hash()When the kernel contains a large number of functions that can be traced,the loop in ftrace_graph_set_hash() may take a lot of time to execute.This may trigger the softlockup watchdog.Add cond_resched() within the loop to allow the kernel to remainresponsive even when processing a large number of functions.This matches the cond_resched() that is used in other locations of thecode that iterates over all functions that can be traced.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: codecs: wcd937x: fix a potential memory leak in wcd937x_soc_codec_probe()When snd_soc_dapm_new_controls() or snd_soc_dapm_add_routes() fails,wcd937x_soc_codec_probe() returns without releasing 'wcd937x->clsh_info',which is allocated by wcd_clsh_ctrl_alloc. Add wcd_clsh_ctrl_free()to prevent potential memory leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifiIn certain cases, hardware might provide packets with alength greater than the maximum native Wi-Fi header length.This can lead to accessing and modifying fields in the headerwithin the ath12k_dp_rx_h_undecap_nwifi function forDP_RX_DECAP_TYPE_NATIVE_WIFI decap type andpotentially resulting in invalid data access and memory corruption.Add a sanity check before processing the SKB to prevent invaliddata access in the undecap native Wi-Fi function for theDP_RX_DECAP_TYPE_NATIVE_WIFI decap type.Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Fix invalid entry fetch in ath12k_dp_mon_srng_processCurrently, ath12k_dp_mon_srng_process uses ath12k_hal_srng_src_get_next_entryto fetch the next entry from the destination ring. This is incorrect becauseath12k_hal_srng_src_get_next_entry is intended for source rings, not destinationrings. This leads to invalid entry fetches, causing potential data corruption orcrashes due to accessing incorrect memory locations. This happens because thesource ring and destination ring have different handling mechanisms and usingthe wrong function results in incorrect pointer arithmetic and ring management.To fix this issue, replace the call to ath12k_hal_srng_src_get_next_entry withath12k_hal_srng_dst_get_next_entry in ath12k_dp_mon_srng_process. This ensuresthat the correct function is used for fetching entries from the destinationring, preventing invalid memory accesses.Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHYDSA has 2 kinds of drivers:1. Those who call dsa_switch_suspend() and dsa_switch_resume() from their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz2. Those who don't: all others. The above methods should be optional.For type 1, dsa_switch_suspend() calls dsa_user_suspend() -> phylink_stop(),and dsa_switch_resume() calls dsa_user_resume() -> phylink_start().These seem good candidates for setting mac_managed_pm = true becausethat is essentially its definition [1], but that does not seem to be thebiggest problem for now, and is not what this change focuses on.Talking strictly about the 2nd category of DSA drivers here (whichdo not have MAC managed PM, meaning that for their attached PHYs,mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full),I have noticed that the following warning from mdio_bus_phy_resume() istriggered: WARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY && phydev->state != PHY_UP);because the PHY state machine is running.It's running as a result of a previous dsa_user_open() -> ... ->phylink_start() -> phy_start() having been initiated by the user.The previous mdio_bus_phy_suspend() was supposed to have calledphy_stop_machine(), but it didn't. So this is why the PHY is in statePHY_NOLINK by the time mdio_bus_phy_resume() runs.mdio_bus_phy_suspend() did not call phy_stop_machine() because forphylink, the phydev->adjust_link function pointer is NULL. This seems atechnicality introduced by commit fddd91016d16 ("phylib: fix PAL statemachine restart on resume"). That commit was written before phylinkexisted, and was intended to avoid crashing with consumer drivers whichdon't use the PHY state machine - phylink always does, when using a PHY.But phylink itself has historically not been developed withsuspend/resume in mind, and apparently not tested too much in thatscenario, allowing this bug to exist unnoticed for so long. Plus, priorto the WARN_ON(), it would have likely been invisible.This issue is not in fact restricted to type 2 DSA drivers (according tothe above ad-hoc classification), but can be extrapolated to any MACdriver with phylink and MDIO-bus-managed PHY PM ops. DSA is just wherethe issue was reported. Assuming mac_managed_pm is set correctly, aquick search indicates the following other drivers might be affected:$ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pmdrivers/net/ethernet/atheros/ag71xx.cdrivers/net/ethernet/microchip/sparx5/sparx5_main.cdrivers/net/ethernet/microchip/lan966x/lan966x_main.cdrivers/net/ethernet/freescale/dpaa2/dpaa2-mac.cdrivers/net/ethernet/freescale/fs_enet/fs_enet-main.cdrivers/net/ethernet/freescale/dpaa/dpaa_eth.cdrivers/net/ethernet/freescale/ucc_geth.cdrivers/net/ethernet/freescale/enetc/enetc_pf_common.cdrivers/net/ethernet/marvell/mvpp2/mvpp2_main.cdrivers/net/ethernet/marvell/mvneta.cdrivers/net/ethernet/marvell/prestera/prestera_main.cdrivers/net/ethernet/mediatek/mtk_eth_soc.cdrivers/net/ethernet/altera/altera_tse_main.cdrivers/net/ethernet/wangxun/txgbe/txgbe_phy.cdrivers/net/ethernet/meta/fbnic/fbnic_phylink.cdrivers/net/ethernet/tehuti/tn40_phy.cdrivers/net/ethernet/mscc/ocelot_net.cMake the existing conditions dependent on the PHY device having aphydev->phy_link_change() implementation equal to the defaultphy_link_change() provided by phylib. Otherwise, we implicitly know thatthe phydev has the phylink-provided phylink_phy_change() callback, andwhen phylink is used, the PHY state machine always needs to be stopped/started on the suspend/resume path. The code is structured as such thatif phydev->phy_link_change() is absent, it is a matter of time until thekernel will crash - no need to further complicate the test.Thus, for the situation where the PM is not managed b---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/pci: Fix duplicate pci_dev_put() in disable_slot() when PF has child VFsWith commit bcb5d6c76903 ("s390/pci: introduce lock to synchronize stateof zpci_dev's") the code to ignore power off of a PF that has child VFswas changed from a direct return to a goto to the unlock andpci_dev_put() section. The change however left the existing pci_dev_put()untouched resulting in a doubple put. This can subsequently cause a useafter free if the struct pci_dev is released in an unexpected state.Fix this by removing the extra pci_dev_put().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xenbus: Use kref to track req lifetimeMarek reported seeing a NULL pointer fault in the xenbus_threadcallstack:BUG: kernel NULL pointer dereference, address: 0000000000000000RIP: e030:__wake_up_common+0x4c/0x180Call Trace: __wake_up_common_lock+0x82/0xd0 process_msg+0x18e/0x2f0 xenbus_thread+0x165/0x1c0process_msg+0x18e is req->cb(req). req->cb is set to xs_wake_up(), athin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seemslike it was xs_wake_up() in this case.It seems like req may have woken up the xs_wait_for_reply(), whichkfree()ed the req. When xenbus_thread resumes, it faults on the zero-eddata.Linux Device Drivers 2nd edition states:"Normally, a wake_up call can cause an immediate reschedule to happen,meaning that other processes might run before wake_up returns."... which would match the behaviour observed.Change to keeping two krefs on each request. One for the caller, andone for xenbus_thread. Each will kref_put() when finished, and the lastwill free it.This use of kref matches the description inDocumentation/core-api/kref.rst
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio-net: free xsk_buffs on error in virtnet_xsk_pool_enable()The selftests added to our CI by Bui Quang Minh recently revealsthat there is a mem leak on the error path of virtnet_xsk_pool_enable():unreferenced object 0xffff88800a68a000 (size 2048): comm "xdp_helper", pid 318, jiffies 4294692778 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): __kvmalloc_node_noprof+0x402/0x570 virtnet_xsk_pool_enable+0x293/0x6a0 (drivers/net/virtio_net.c:5882) xp_assign_dev+0x369/0x670 (net/xdp/xsk_buff_pool.c:226) xsk_bind+0x6a5/0x1ae0 __sys_bind+0x15e/0x230 __x64_sys_bind+0x72/0xb0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interceptionPreviously, commit ed129ec9057f ("KVM: x86: forcibly leave nested modeon vCPU reset") addressed an issue where a triple fault occurring innested mode could lead to use-after-free scenarios. However, the commitdid not handle the analogous situation for System Management Mode (SMM).This omission results in triggering a WARN when KVM forces a vCPU INITafter SHUTDOWN interception while the vCPU is in SMM. This situation wasreprodused using Syzkaller by: 1) Creating a KVM VM and vCPU 2) Sending a KVM_SMI ioctl to explicitly enter SMM 3) Executing invalid instructions causing consecutive exceptions and eventually a triple faultThe issue manifests as follows: WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112 kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Modules linked in: CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted 6.1.130-syzkaller-00157-g164fe5dde9b6 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Call Trace: shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136 svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395 svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457 vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline] vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062 kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283 kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8Architecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN()in kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improperemulation of INIT. SHUTDOWN on SVM is a weird edge case where KVM needs todo _something_ sane with the VMCB, since it's technically undefined, andINIT is the least awful choice given KVM's ABI.So, double down on stuffing INIT on SHUTDOWN, and force the vCPU out ofSMM to avoid any weirdness (and the WARN).Found by Linux Verification Center (linuxtesting.org) with Syzkaller.[sean: massage changelog, make it clear this isn't architectural behavior]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Scrub packet on bpf_redirect_peerWhen bpf_redirect_peer is used to redirect packets to a device inanother network namespace, the skb isn't scrubbed. That can lead skbinformation from one namespace to be "misused" in another namespace.As one example, this is causing Cilium to drop traffic when usingbpf_redirect_peer to redirect packets that just went through IPsecdecryption to a container namespace. The following pwru trace shows (1)the packet path from the host's XFRM layer to the container's XFRMlayer where it's dropped and (2) the number of active skb extensions ateach function. NETNS MARK IFACE TUPLE FUNC 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive .active_extensions = (__u8)2, [...] 4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core .active_extensions = (__u8)2, [...] 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY) .active_extensions = (__u8)2,In this case, there are no XFRM policies in the container's networknamespace so the drop is unexpected. When we decrypt the IPsec packet,the XFRM state used for decryption is set in the skb extensions. Thisinformation is preserved across the netns switch. When we reach theXFRM policy check in the container's netns, __xfrm_policy_check dropsthe packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRMpolicy can't be found that matches the (host-side) XFRM state used fordecryption.This patch fixes this by scrubbing the packet when usingbpf_redirect_peer, as is done on typical netns switches via vethdevices except skb->mark and skb->tstamp are not zeroed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:memblock: Accept allocated memory before use in memblock_double_array()When increasing the array size in memblock_double_array() and the slabis not yet available, a call to memblock_find_in_range() is used toreserve/allocate memory. However, the range returned may not have beenaccepted, which can result in a crash when booting an SNP guest: RIP: 0010:memcpy_orig+0x68/0x130 Code: ... RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006 RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000 RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00 RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000 R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78 R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00 memblock_double_array+0xff/0x310 memblock_add_range+0x1fb/0x2f0 memblock_reserve+0x4f/0xa0 memblock_alloc_range_nid+0xac/0x130 memblock_alloc_internal+0x53/0xc0 memblock_alloc_try_nid+0x3d/0xa0 swiotlb_init_remap+0x149/0x2f0 mem_init+0xb/0xb0 mm_core_init+0x8f/0x350 start_kernel+0x17e/0x5d0 x86_64_start_reservations+0x14/0x30 x86_64_start_kernel+0x92/0xa0 secondary_startup_64_no_verify+0x194/0x19bMitigate this by calling accept_memory() on the memory range returnedbefore the slab is available.Prior to v6.12, the accept_memory() interface used a 'start' and 'end'parameter instead of 'start' and 'size', therefore the accept_memory()call must be adjusted to specify 'start + size' for 'end' when applyingto kernels prior to v6.12.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix uninit-value for saddr in do_output_route4syzbot reports for uninit-value for the saddr argument [1].commit 4754957f04f5 ("ipvs: do not use random local source address fortunnels") already implies that the input value of saddrshould be ignored but the code is still reading it which can preventto connect the route. Fix it by changing the argument to ret_saddr.[1]BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8eUninit was created at: slab_post_alloc_hook mm/slub.c:4167 [inline] slab_alloc_node mm/slub.c:4210 [inline] __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline] __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8eCPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef)Hardware name: Google Google Compute Engi---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:riscv: Fix kernel crash due to PR_SET_TAGGED_ADDR_CTRLWhen userspace does PR_SET_TAGGED_ADDR_CTRL, but Supm extension is notavailable, the kernel crashes:Oops - illegal instruction [#1] [snip]epc : set_tagged_addr_ctrl+0x112/0x15a ra : set_tagged_addr_ctrl+0x74/0x15aepc : ffffffff80011ace ra : ffffffff80011a30 sp : ffffffc60039be10 [snip]status: 0000000200000120 badaddr: 0000000010a79073 cause: 0000000000000002 set_tagged_addr_ctrl+0x112/0x15a __riscv_sys_prctl+0x352/0x73c do_trap_ecall_u+0x17c/0x20c andle_exception+0x150/0x15cFix it by checking if Supm is available.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: displayport: Fix deadlockThis patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlockfunctions to the UCSI driver. ucsi_con_mutex_lock ensures the connectormutex is only locked if a connection is established and the partner pointeris valid. This resolves a deadlock scenario whereucsi_displayport_remove_partner holds con->mutex waiting fordp_altmode_work to complete while dp_altmode_work attempts to acquire it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: opt3001: fix deadlock due to concurrent flag accessThe threaded IRQ function in this driver is reading the flag twice: once tolock a mutex and once to unlock it. Even though the code setting the flagis designed to prevent it, there are subtle cases where the flag could betrue at the mutex_lock stage and false at the mutex_unlock stage. Thisresults in the mutex not being unlocked, resulting in a deadlock.Fix it by making the opt3001_irq() code generally more robust, reading theflag into a variable and using the variable value at both stages.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifoPrevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop incase pattern_len is equal to zero and the device FIFO is not empty.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifoPrevent st_lsm6dsx_read_fifo from falling in an infinite loop in casepattern_len is equal to zero and the device FIFO is not empty.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: bcm2835-camera: Initialise dev in v4l2_devCommit 42a2f6664e18 ("staging: vc04_services: Move global g_state tovchiq_state") changed mmal_init to pass dev->v4l2_dev.dev tovchiq_mmal_init, however nothing iniitialised dev->v4l2_dev, so we gota NULL pointer dereference.Set dev->v4l2_dev.dev during bcm2835_mmal_probe. The device pointercould be passed into v4l2_device_register to set it, however that alsohas other effects that would need additional changes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: mtk-pmic-keys - fix possible null pointer dereferenceIn mtk_pmic_keys_probe, the regs parameter is only set if the button isparsed in the device tree. However, on hardware where the button is leftfloating, that node will most likely be removed not to enable thatinput. In that case the code will try to dereference a null pointer.Let's use the regs struct instead as it is defined for all supportedplatforms. Note that it is ok setting the key reg even if that latter isdisabled as the interrupt won't be enabled anyway.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: fix out-of-bounds access during multi-link element defragmentationCurrently during the multi-link element defragmentation process, themulti-link element length added to the total IEs length when calculatingthe length of remaining IEs after the multi-link element incfg80211_defrag_mle(). This could lead to out-of-bounds access if themulti-link element or its corresponding fragment elements are the lastelements in the IEs buffer.To address this issue, correctly calculate the remaining IEs length bydeducting the multi-link element end offset from total IEs end offset.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/pci: Fix missing check for zpci_create_device() error returnThe zpci_create_device() function returns an error pointer that needs tobe checked before dereferencing it as a struct zpci_dev pointer. Add themissing check in __clp_add() where it was missed when adding thescan_list in the fixed commit. Simply not adding the device to the scanlist results in the previous behavior.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:riscv: module: Fix out-of-bounds relocation accessThe current code allows rel[j] to access one element past the end of therelocation section. Simplify to num_relocations which is equivalent tothe existing size expression.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: exynos: Disable iocc if dma-coherent property isn't setIf dma-coherent property isn't set then descriptors are non-cacheableand the iocc shareability bits should be disabled. Without this UFS canend up in an incompatible configuration and suffer from random cacherelated stability issues.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: integrity: Do not call set_page_dirty_lock()Placing multiple protection information buffers inside the same pagecan lead to oopses because set_page_dirty_lock() can't be called frominterrupt context.Since a protection information buffer is not backed by a file there isno point in setting its page dirty, there is nothing to synchronize.Drop the call to set_page_dirty_lock() and remove the last argument tobio_integrity_unpin_bvec().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: qcom: Fix sc7280 lpass potential buffer overflowCase values introduced in commit5f78e1fb7a3e ("ASoC: qcom: Add driver support for audioreach solution")cause out of bounds access in arrays of sc7280 driver data (e.g. in caseof RX_CODEC_DMA_RX_0 in sc7280_snd_hw_params()).Redefine LPASS_MAX_PORTS to consider the maximum possible port id forq6dsp as sc7280 driver utilizes some of those values.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: fix resource leak in blk_register_queue() error pathWhen registering a queue fails after blk_mq_sysfs_register() issuccessful but the function later encounters an error, we needto clean up the blk_mq_sysfs resources.Add the missing blk_mq_sysfs_unregister() call in the error pathto properly clean up these resources and prevent a memory leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: smartpqi: Use is_kdump_kernel() to check for kdumpThe smartpqi driver checks the reset_devices variable to determinewhether special adjustments need to be made for kdump. This has theeffect that after a regular kexec reboot, some driver parameters such asmax_transfer_size are much lower than usual. More importantly, kexecreboot tests have revealed memory corruption caused by the driver logbeing written to system memory after a kexec.Fix this by testing is_kdump_kernel() rather than reset_devices whereappropriate.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wl1251: fix memory leak in wl1251_tx_workThe skb dequeued from tx_queue is lost when wl1251_ps_elp_wakeup failswith a -ETIMEDOUT error. Fix that by queueing the skb back to tx_queue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: wdm: close race between wdm_open and wdm_wwan_port_stopClearing WDM_WWAN_IN_USE must be the last action orwe can open a chardev whose URBs are still poisoned
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: class: Invalidate USB device pointers on partner unregistrationTo avoid using invalid USB device pointers after a Type-C partnerdisconnects, this patch clears the pointers upon partner unregistration.This ensures a clean state for future connections.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pds_core: Prevent possible adminq overflow/stuck conditionThe pds_core's adminq is protected by the adminq_lock, which preventsmore than 1 command to be posted onto it at any one time. This makes itso the client drivers cannot simultaneously post adminq commands.However, the completions happen in a different context, which meansmultiple adminq commands can be posted sequentially and all waitingon completion.On the FW side, the backing adminq request queue is only 16 entrieslong and the retry mechanism and/or overflow/stuck prevention islacking. This can cause the adminq to get stuck, so commands are nolonger processed and completions are no longer sent by the FW.As an initial fix, prevent more than 16 outstanding adminq commands sothere's no way to cause the adminq from getting stuck. This worksbecause the backing adminq request queue will never have more than 16pending adminq commands, so it will never overflow. This is done byreducing the adminq depth to 16.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fix a couple of races in MNT_TREE_BENEATH handling by do_move_mount()Normally do_lock_mount(path, _) is locking a mountpoint pinned by*path and at the time when matching unlock_mount() unlocks thatlocation it is still pinned by the same thing.Unfortunately, for 'beneath' case it's no longer that simple -the object being locked is not the one *path points to. It's themountpoint of path->mnt. The thing is, without sufficient locking->mnt_parent may change under us and none of the locks are heldat that point. The rules are * mount_lock stabilizes m->mnt_parent for any mount m. * namespace_sem stabilizes m->mnt_parent, provided thatm is mounted. * if either of the above holds and refcount of m is positive,we are guaranteed the same for refcount of m->mnt_parent.namespace_sem nests inside inode_lock(), so do_lock_mount() hasto take inode_lock() before grabbing namespace_sem. It doesrecheck that path->mnt is still mounted in the same place aftergetting namespace_sem, and it does take care to pin the dentry.It is needed, since otherwise we might end up with racing mount --move(or umount) happening while we were getting locks; in that casedentry would no longer be a mountpoint and could've been evictedon memory pressure along with its inode - not something you wantwhen grabbing lock on that inode.However, pinning a dentry is not enough - the matching mount isalso pinned only by the fact that path->mnt is mounted on top itand at that point we are not holding any locks whatsoever, sothe same kind of races could end up with all references tothat mount gone just as we are about to enter inode_lock().If that happens, we are left with filesystem being shut down whilewe are holding a dentry reference on it; results are not pretty.What we need to do is grab both dentry and mount at the same time;that makes inode_lock() safe *and* avoids the problem with fs gettingshut down under us. After taking namespace_sem we verify thatpath->mnt is still mounted (which stabilizes its ->mnt_parent) andcheck that it's still mounted at the same place. From that pointon to the matching namespace_unlock() we are guaranteed thatmount/dentry pair we'd grabbed are also pinned by being the mountpointof path->mnt, so we can quietly drop both the dentry reference (asthe current code does) and mnt one - it's OK to do under namespace_sem,since we are not dropping the final refs.That solves the problem on do_lock_mount() side; unlock_mount()also has one, since dentry is guaranteed to stay pinned only untilthe namespace_unlock(). That's easy to fix - just have inode_unlock()done earlier, while it's still pinned by mp->m_dentry.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: leds: fix memory leakA network restart test on a router led to an out-of-memory condition,which was traced to a memory leak in the PHY LED trigger code.The root cause is misuse of the devm API. The registration function(phy_led_triggers_register) is called from phy_attach_direct, notphy_probe, and the unregister function (phy_led_triggers_unregister)is called from phy_detach, not phy_remove. This means the register andunregister functions can be called multiple times for the same PHYdevice, but devm-allocated memory is not freed until the driver isunbound.This also prevents kmemleak from detecting the leak, as the devm APIinternally stores the allocated pointer.Fix this by replacing devm_kzalloc/devm_kcalloc with standardkzalloc/kcalloc, and add the corresponding kfree calls in the unregisterpath.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()The function brcmf_usb_dl_writeimage() calls the functionbrcmf_usb_dl_cmd() but dose not check its return value. The'state.state' and the 'state.bytes' are uninitialized if thefunction brcmf_usb_dl_cmd() fails. It is dangerous to useuninitialized variables in the conditions.Add error handling for brcmf_usb_dl_cmd() to jump to errorhandling path if the brcmf_usb_dl_cmd() fails and the'state.state' and the 'state.bytes' are uninitialized.Improve the error message to report more detailed errorinformation.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: Flush gso_skb list too during ->change()Previously, when reducing a qdisc's limit via the ->change() operation, onlythe main skb queue was trimmed, potentially leaving packets in the gso_skblist. This could result in NULL pointer dereference when we only checksch->limit against sch->q.qlen.This patch introduces a new helper, qdisc_dequeue_internal(), which ensuresboth the gso_skb list and the main queue are properly flushed when trimmingexcess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie)are updated to use this helper in their ->change() routines.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:module: ensure that kobject_put() is safe for module type kobjectsIn 'lookup_or_create_module_kobject()', an internal kobject is createdusing 'module_ktype'. So call to 'kobject_put()' on error handlingpath causes an attempt to use an uninitialized completion pointer in'module_kobject_release()'. In this scenario, we just want to releasekobject without an extra synchronization required for a regular moduleunloading process, so adding an extra check whether 'complete()' isactually required makes 'kobject_put()' safe.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Disable MACsec offload for uplink representor profileMACsec offload is not supported in switchdev mode for uplinkrepresentors. When switching to the uplink representor profile, theMACsec offload feature must be cleared from the netdevice's features.If left enabled, attempts to add offloads result in a null pointerdereference, as the uplink representor does not support MACsec offloadeven though the feature bit remains set.Clear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features().Kernel log:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASANKASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]CPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:__mutex_lock+0x128/0x1dd0Code: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ffRSP: 0018:ffff888147a4f160 EFLAGS: 00010206RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001RDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078RBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400Call Trace: ? die_addr+0x3d/0xa0 ? exc_general_protection+0x144/0x220 ? asm_exc_general_protection+0x22/0x30 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? __mutex_lock+0x128/0x1dd0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mutex_lock_io_nested+0x1ae0/0x1ae0 ? lock_acquire+0x1c2/0x530 ? macsec_upd_offload+0x145/0x380 ? lockdep_hardirqs_on_prepare+0x400/0x400 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 ? __kasan_kmalloc+0x77/0x90 ? __kmalloc_noprof+0x249/0x6b0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core] macsec_update_offload+0x26c/0x820 ? macsec_set_mac_address+0x4b0/0x4b0 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? _raw_spin_unlock_irqrestore+0x47/0x50 macsec_upd_offload+0x2c8/0x380 ? macsec_update_offload+0x820/0x820 ? __nla_parse+0x22/0x30 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240 genl_family_rcv_msg_doit+0x1cc/0x2a0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240 ? cap_capable+0xd4/0x330 genl_rcv_msg+0x3ea/0x670 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? macsec_update_offload+0x820/0x820 netlink_rcv_skb+0x12b/0x390 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? netlink_ack+0xd80/0xd80 ? rwsem_down_read_slowpath+0xf90/0xf90 ? netlink_deliver_tap+0xcd/0xac0 ? netlink_deliver_tap+0x155/0xac0 ? _copy_from_iter+0x1bb/0x12c0 genl_rcv+0x24/0x40 netlink_unicast+0x440/0x700 ? netlink_attachskb+0x760/0x760 ? lock_acquire+0x1c2/0x530 ? __might_fault+0xbb/0x170 netlink_sendmsg+0x749/0xc10 ? netlink_unicast+0x700/0x700 ? __might_fault+0xbb/0x170 ? netlink_unicast+0x700/0x700 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x53f/0x760 ? import_iovec+0x7/0x10 ? kernel_sendmsg+0x30/0x30 ? __copy_msghdr+0x3c0/0x3c0 ? filter_irq_stacks+0x90/0x90 ? stack_depot_save_flags+0x28/0xa30 ___sys_sen---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfs: handle failure of nfs_get_lock_context in unlock pathWhen memory is insufficient, the allocation of nfs_lock_context innfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treatan nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)as valid and proceed to execute rpc_run_task(), this will trigger a NULLpointer dereference in nfs4_locku_prepare. For example:BUG: kernel NULL pointer dereference, address: 000000000000000cPGD 0 P4D 0Oops: Oops: 0000 [#1] SMP PTICPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40Workqueue: rpciod rpc_async_scheduleRIP: 0010:nfs4_locku_prepare+0x35/0xc2Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0Call Trace: __rpc_execute+0xbc/0x480 rpc_async_schedule+0x2f/0x40 process_one_work+0x232/0x5d0 worker_thread+0x1da/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x240 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in:CR2: 000000000000000c---[ end trace 0000000000000000 ]---Free the allocated nfs4_unlockdata when nfs_get_lock_context() fails andreturn NULL to terminate subsequent rpc_run_task, preventing NULL pointerdereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bugCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0 fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fIn the function rxe_create_cq, when rxe_cq_from_init fails, the functionrxe_cleanup will be called to handle the allocated resources. In fact,some memory resources have already been freed in the functionrxe_cq_from_init. Thus, this problem will occur.The solution is to let rxe_cleanup do all the work.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Fix use-after-free in cifs_fill_direntThere is a race condition in the readdir concurrency process, which mayaccess the rsp buffer after it has been released, triggering thefollowing KASAN warning. ================================================================== BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975 CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================POC is available in the link [1].The problem triggering process is as follows:Process 1 Process 2--------------------------------------truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_doneSyzbot reported a slab-use-after-free with the following call trace: ================================================================== BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25 Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394 Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_donemay still visit it in cryptd_queue_worker workqueue.I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1The key of reproduction is that, simd_aead_encrypt is interrupted, leadingto crypto_simd_usable() return false. Thus, the cryptd_queue_worker istriggered, and the tipc_crypto tx will be visited. tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base; simd_aead_encrypt crypto_aead_encrypt // encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work)Fix this by holding net reference count before encrypt.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix null-ptr-deref in idpf_features_checkidpf_features_check is used to validate the TX packet. skb headerlength is compared with the hardware supported value received fromthe device control plane. The value is stored in the adapter structureand to access it, vport pointer is used. During reset all the vportsare released and the vport pointer that the netdev private structurepoints to is NULL.To avoid null-ptr-deref, store the max header length value in netdevprivate structure. This also helps to cache the value and avoidaccessing adapter pointer in hot path.BUG: kernel NULL pointer dereference, address: 0000000000000068...RIP: 0010:idpf_features_check+0x6d/0xe0 [idpf]Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x154/0x520 ? exc_page_fault+0x76/0x190 ? asm_exc_page_fault+0x26/0x30 ? idpf_features_check+0x6d/0xe0 [idpf] netif_skb_features+0x88/0x310 validate_xmit_skb+0x2a/0x2b0 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x19d/0x3a0 __dev_queue_xmit+0xb74/0xe70 ...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: ocp: Limit signal/freq counts in summary output functionsThe debugfs summary output could access uninitialized elements inthe freq_in[] and signal_out[] arrays, causing NULL pointerdereferences and triggering a kernel Oops (page_fault_oops).This patch adds u8 fields (nr_freq_in, nr_signal_out) to track thenumber of initialized elements, with a maximum of 4 per array.The summary output functions are updated to respect these limits,preventing out-of-bounds access and ensuring safe array handling.Widen the label variables because the change confuses GCC aboutmax length of the strings.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel: Fix segfault with PEBS-via-PT with sample_freqCurrently, using PEBS-via-PT with a sample frequency instead of a sampleperiod, causes a segfault. For example: BUG: kernel NULL pointer dereference, address: 0000000000000195 ? __die_body.cold+0x19/0x27 ? page_fault_oops+0xca/0x290 ? exc_page_fault+0x7e/0x1b0 ? asm_exc_page_fault+0x26/0x30 ? intel_pmu_pebs_event_update_no_drain+0x40/0x60 ? intel_pmu_pebs_event_update_no_drain+0x32/0x60 intel_pmu_drain_pebs_icl+0x333/0x350 handle_pmi_common+0x272/0x3c0 intel_pmu_handle_irq+0x10a/0x2e0 perf_event_nmi_handler+0x2a/0x50That happens because intel_pmu_pebs_event_update_no_drain() assumes all thepebs_enabled bits represent counter indexes, which is not always the case.In this particular case, bits 60 and 61 are set for PEBS-via-PT purposes.The behaviour of PEBS-via-PT with sample frequency is questionable becausealthough a PMI is generated (PEBS_PMI_AFTER_EACH_RECORD), the period is notadjusted anyway.Putting that aside, fix intel_pmu_pebs_event_update_no_drain() by passingthe mask of counter bits instead of 'size'. Note, prior to the Fixescommit, 'size' would be limited to the maximum counter index, so the issuewas not hit.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Intel: hda: Fix UAF when reloading modulehda_generic_machine_select() appends -idisp to the tplg filename byallocating a new string with devm_kasprintf(), then stores the stringright back into the global variable snd_soc_acpi_intel_hda_machines.When the module is unloaded, this memory is freed, resulting in a globalvariable pointing to freed memory. Reloading the module then triggersa use-after-free:BUG: KFENCE: use-after-free read in string+0x48/0xe0Use-after-free read at 0x00000000967e0109 (in kfence-#99): string+0x48/0xe0 vsnprintf+0x329/0x6e0 devm_kvasprintf+0x54/0xb0 devm_kasprintf+0x58/0x80 hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] sof_probe_work+0x7f/0x600 [snd_sof] process_one_work+0x17b/0x330 worker_thread+0x2ce/0x3f0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30kfence-#99: 0x00000000198a940f-0x00000000ace47d9d, size=64, cache=kmalloc-64allocated by task 333 on cpu 8 at 17.798069s (130.453553s ago): devm_kmalloc+0x52/0x120 devm_kvasprintf+0x66/0xb0 devm_kasprintf+0x58/0x80 hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] sof_probe_work+0x7f/0x600 [snd_sof] process_one_work+0x17b/0x330 worker_thread+0x2ce/0x3f0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30freed by task 1543 on cpu 4 at 141.586686s (6.665010s ago): release_nodes+0x43/0xb0 devres_release_all+0x90/0xf0 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c1/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x42/0xb0 __do_sys_delete_module+0x1d1/0x310 do_syscall_64+0x82/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7eFix it by copying the match array with devm_kmemdup_array() before wemodify it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:espintcp: fix skb leaksA few error paths are missing a kfree_skb.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libnvdimm/labels: Fix divide error in nd_label_data_init()If a faulty CXL memory device returns a broken zero LSA size in itsmemory device information (Identify Memory Device (Opcode 4000h), CXLspec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimmdriver: Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]Code and flow:1) CXL Command 4000h returns LSA size = 02) config_size is assigned to zero LSA size (CXL pmem driver):drivers/cxl/pmem.c: .config_size = mds->lsa_size,3) max_xfer is set to zero (nvdimm driver):drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size);4) A subsequent DIV_ROUND_UP() causes a division by zero:drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer,drivers/nvdimm/label.c- config_size);Fix this by checking the config size parameter by extending anexisting check.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell-wmi-sysman: Avoid buffer overflow in current_password_store()If the 'buf' array received from the user contains an empty string, the'length' variable will be zero. Accessing the 'buf' array element withindex 'length - 1' will result in a buffer overflow.Add a check for an empty string.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: Fix race of buffer access at PCM OSS layerThe PCM OSS layer tries to clear the buffer with the silence data atinitialization (or reconfiguration) of a stream with the explicit callof snd_pcm_format_set_silence() with runtime->dma_area. But this maylead to a UAF because the accessed runtime->dma_area might be freedconcurrently, as it's performed outside the PCM ops.For avoiding it, move the code into the PCM core and perform it insidethe buffer access lock, so that it won't be changed during theoperation.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: cadence: macb: Fix a possible deadlock in macb_halt_tx.There is a situation where after THALT is set high, TGO stays high aswell. Because jiffies are never updated, as we are in a context withinterrupts disabled, we never exit that loop and have a deadlock.That deadlock was noticed on a sama5d4 device that stayed locked for days.Use retries instead of jiffies so that the timeout really works and we donot have a deadlock anymore.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf: insert memory barrier before updating num_fencessmp_store_mb() inserts memory barrier after storing operation.It is different with what the comment is originally aiming so Nullpointer dereference can be happened if memory update is reordered.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: don't warn when if there is a FW erroriwl_trans_reclaim is warning if it is called when the FW is not alive.But if it is called when there is a pending restart, i.e. after a FWerror, there is no need to warn, instead - return silently.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Replace Mutex with Spinlock for RLCG register access to avoid Priority Inversion in SRIOVRLCG Register Access is a way for virtual functions to safely access GPUregisters in a virtualized environment., including TLB flushes andregister reads. When multiple threads or VFs try to access the sameregisters simultaneously, it can lead to race conditions. By using theRLCG interface, the driver can serialize access to the registers. Thismeans that only one thread can access the registers at a time,preventing conflicts and ensuring that operations are performedcorrectly. Additionally, when a low-priority task holds a mutex that ahigh-priority task needs, ie., If a thread holding a spinlock tries toacquire a mutex, it can lead to priority inversion. register access inamdgpu_virt_rlcg_reg_rw especially in a fast code path is critical.The call stack shows that the function amdgpu_virt_rlcg_reg_rw is beingcalled, which attempts to acquire the mutex. This function is invokedfrom amdgpu_sriov_wreg, which in turn is called fromgmc_v11_0_flush_gpu_tlb.The [ BUG: Invalid wait context ] indicates that a thread is trying toacquire a mutex while it is in a context that does not allow it to sleep(like holding a spinlock).Fixes the below:[ 253.013423] =============================[ 253.013434] [ BUG: Invalid wait context ][ 253.013446] 6.12.0-amdstaging-drm-next-lol-050225 #14 Tainted: G U OE[ 253.013464] -----------------------------[ 253.013475] kworker/0:1/10 is trying to lock:[ 253.013487] ffff9f30542e3cf8 (&adev->virt.rlcg_reg_lock){+.+.}-{3:3}, at: amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu][ 253.013815] other info that might help us debug this:[ 253.013827] context-{4:4}[ 253.013835] 3 locks held by kworker/0:1/10:[ 253.013847] #0: ffff9f3040050f58 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x3f5/0x680[ 253.013877] #1: ffffb789c008be40 ((work_completion)(&wfc.work)){+.+.}-{0:0}, at: process_one_work+0x1d6/0x680[ 253.013905] #2: ffff9f3054281838 (&adev->gmc.invalidate_lock){+.+.}-{2:2}, at: gmc_v11_0_flush_gpu_tlb+0x198/0x4f0 [amdgpu][ 253.014154] stack backtrace:[ 253.014164] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Tainted: G U OE 6.12.0-amdstaging-drm-next-lol-050225 #14[ 253.014189] Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE[ 253.014203] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/18/2024[ 253.014224] Workqueue: events work_for_cpu_fn[ 253.014241] Call Trace:[ 253.014250] [ 253.014260] dump_stack_lvl+0x9b/0xf0[ 253.014275] dump_stack+0x10/0x20[ 253.014287] __lock_acquire+0xa47/0x2810[ 253.014303] ? srso_alias_return_thunk+0x5/0xfbef5[ 253.014321] lock_acquire+0xd1/0x300[ 253.014333] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu][ 253.014562] ? __lock_acquire+0xa6b/0x2810[ 253.014578] __mutex_lock+0x85/0xe20[ 253.014591] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu][ 253.014782] ? sched_clock_noinstr+0x9/0x10[ 253.014795] ? srso_alias_return_thunk+0x5/0xfbef5[ 253.014808] ? local_clock_noinstr+0xe/0xc0[ 253.014822] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu][ 253.015012] ? srso_alias_return_thunk+0x5/0xfbef5[ 253.015029] mutex_lock_nested+0x1b/0x30[ 253.015044] ? mutex_lock_nested+0x1b/0x30[ 253.015057] amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu][ 253.015249] amdgpu_sriov_wreg+0xc5/0xd0 [amdgpu][ 253.015435] gmc_v11_0_flush_gpu_tlb+0x44b/0x4f0 [amdgpu][ 253.015667] gfx_v11_0_hw_init+0x499/0x29c0 [amdgpu][ 253.015901] ? __pfx_smu_v13_0_update_pcie_parameters+0x10/0x10 [amdgpu][ 253.016159] ? srso_alias_return_thunk+0x5/0xfbef5[ 253.016173] ? smu_hw_init+0x18d/0x300 [amdgpu][ 253.016403] amdgpu_device_init+0x29ad/0x36a0 [amdgpu][ 253.016614] amdgpu_driver_load_kms+0x1a/0xc0 [amdgpu][ 253.0170---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: CPPC: Fix NULL pointer dereference when nosmp is usedWith nosmp in cmdline, other CPUs are not brought up, leavingtheir cpc_desc_ptr NULL. CPU0's iteration via for_each_possible_cpu()dereferences these NULL pointers, causing panic.Panic backtrace:[ 0.401123] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b8...[ 0.403255] [] cppc_allow_fast_switch+0x6a/0xd4...Kernel panic - not syncing: Attempted to kill init![ rjw: New subject ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: sch_sfq: fix a potential crash on gso_skb handlingSFQ has an assumption of always being able to queue at least one packet.However, after the blamed commit, sch->q.len can be inflated by packetsin sch->gso_skb, and an enqueue() on an empty SFQ qdisc can be followedby an immediate drop.Fix sfq_drop() to properly clear q->tail in this situation.ip netns add lbip link add dev to-lb type veth peer name in-lb netns lbethtool -K to-lb tso off # force qdisc to requeue gso_skbip netns exec lb ethtool -K in-lb gro on # enable NAPIip link set dev to-lb upip -netns lb link set dev in-lb upip addr add dev to-lb 192.168.20.1/24ip -netns lb addr add dev in-lb 192.168.20.2/24tc qdisc replace dev to-lb root sfq limit 100ip netns exec lb netservernetperf -H 192.168.20.2 -l 100 &netperf -H 192.168.20.2 -l 100 &netperf -H 192.168.20.2 -l 100 &netperf -H 192.168.20.2 -l 100 &
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: ufs: Fix a hang in the error handlerufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latterfunction can only succeed if UFSHCD_EH_IN_PROGRESS is not set becauseresuming involves submitting a SCSI command and ufshcd_queuecommand()returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix thishang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() hasbeen called instead of before.Backtrace:__switch_to+0x174/0x338__schedule+0x600/0x9e4schedule+0x7c/0xe8schedule_timeout+0xa4/0x1c8io_schedule_timeout+0x48/0x70wait_for_common_io+0xa8/0x160 //waiting on START_STOPwait_for_completion_io_timeout+0x10/0x20blk_execute_rq+0xe4/0x1e4scsi_execute_cmd+0x108/0x244ufshcd_set_dev_pwr_mode+0xe8/0x250__ufshcd_wl_resume+0x94/0x354ufshcd_wl_runtime_resume+0x3c/0x174scsi_runtime_resume+0x64/0xa4rpm_resume+0x15c/0xa1c__pm_runtime_resume+0x4c/0x90 // Runtime resume ongoingufshcd_err_handler+0x1a0/0xd08process_one_work+0x174/0x808worker_thread+0x15c/0x490kthread+0xf4/0x1ecret_from_fork+0x10/0x20[ bvanassche: rewrote patch description ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: add missing NULL check for gve_alloc_pending_packet() in TX DQOgve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo()did not check for this case before dereferencing the returned pointer.Add a missing NULL check to prevent a potential NULL pointerdereference when allocation fails.This improves robustness in low-memory scenarios.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix Tx scheduler error handling in XDP callbackWhen the XDP program is loaded, the XDP callback adds new Tx queues.This means that the callback must update the Tx scheduler with the newqueue number. In the event of a Tx scheduler failure, the XDP callbackshould also fail and roll back any changes previously made for XDPpreparation.The previous implementation had a bug that not all changes made by theXDP callback were rolled back. This caused the crash with the followingcall trace:[ +9.549584] ice 0000:ca:00.0: Failed VSI LAN queue config for XDP, error: -5[ +0.382335] Oops: general protection fault, probably for non-canonical address 0x50a2250a90495525: 0000 [#1] SMP NOPTI[ +0.010710] CPU: 103 UID: 0 PID: 0 Comm: swapper/103 Not tainted 6.14.0-net-next-mar-31+ #14 PREEMPT(voluntary)[ +0.010175] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022[ +0.010946] RIP: 0010:__ice_update_sample+0x39/0xe0 [ice][...][ +0.002715] Call Trace:[ +0.002452] [ +0.002021] ? __die_body.cold+0x19/0x29[ +0.003922] ? die_addr+0x3c/0x60[ +0.003319] ? exc_general_protection+0x17c/0x400[ +0.004707] ? asm_exc_general_protection+0x26/0x30[ +0.004879] ? __ice_update_sample+0x39/0xe0 [ice][ +0.004835] ice_napi_poll+0x665/0x680 [ice][ +0.004320] __napi_poll+0x28/0x190[ +0.003500] net_rx_action+0x198/0x360[ +0.003752] ? update_rq_clock+0x39/0x220[ +0.004013] handle_softirqs+0xf1/0x340[ +0.003840] ? sched_clock_cpu+0xf/0x1f0[ +0.003925] __irq_exit_rcu+0xc2/0xe0[ +0.003665] common_interrupt+0x85/0xa0[ +0.003839] [ +0.002098] [ +0.002106] asm_common_interrupt+0x26/0x40[ +0.004184] RIP: 0010:cpuidle_enter_state+0xd3/0x690Fix this by performing the missing unmapping of XDP queues fromq_vectors and setting the XDP rings pointer back to NULL after all thosequeues are released.Also, add an immediate exit from the XDP callback in case of ringpreparation failure.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: Add NULL check in udma_probe()devm_kasprintf() returns NULL when memory allocation fails. Currently,udma_probe() does not check for this case, which results in a NULLpointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:backlight: pm8941: Add NULL check in wled_configure()devm_kasprintf() returns NULL when memory allocation fails. Currently,wled_configure() does not check for this case, which results in a NULLpointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: aspeed: Add NULL check in aspeed_lpc_enable_snoop()devm_kasprintf() returns NULL when memory allocation fails. Currently,aspeed_lpc_enable_snoop() does not check for this case, which results in aNULL pointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.[arj: Fix Fixes: tag to use subject from 3772e5da4454]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:calipso: Don't call calipso functions for AF_INET sk.syzkaller reported a null-ptr-deref in txopt_get(). [0]The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo,so struct ipv6_pinfo was NULL there.However, this never happens for IPv6 sockets as inet_sk(sk)->pinet6is always set in inet6_create(), meaning the socket was not IPv6 one.The root cause is missing validation in netlbl_conn_setattr().netlbl_conn_setattr() switches branches based on structsockaddr.sa_family, which is passed from userspace. However,netlbl_conn_setattr() does not check if the address family matchesthe socket.The syzkaller must have called connect() for an IPv6 address onan IPv4 socket.We have a proper validation in tcp_v[46]_connect(), butsecurity_socket_connect() is called in the earlier stage.Let's copy the validation to netlbl_conn_setattr().[0]:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]CPU: 2 UID: 0 PID: 12928 Comm: syz.9.1677 Not tainted 6.12.0 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:txopt_get include/net/ipv6.h:390 [inline]RIP: 0010:Code: 02 00 00 49 8b ac 24 f8 02 00 00 e8 84 69 2a fd e8 ff 00 16 fd 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 53 02 00 00 48 8b 6d 70 48 85 ed 0f 84 ab 01 00RSP: 0018:ffff88811b8afc48 EFLAGS: 00010212RAX: dffffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00cRDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000070RBP: 0000000000000000 R08: ffffed1023715f9d R09: ffffed1023715f9eR10: ffffed1023715f9d R11: 0000000000000003 R12: ffff888123075f00R13: ffff88810245bd80 R14: ffff888113646780 R15: ffff888100578a80FS: 00007f9019bd7640(0000) GS:ffff8882d2d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f901b927bac CR3: 0000000104788003 CR4: 0000000000770ef0PKRU: 80000000Call Trace: calipso_sock_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:557 netlbl_conn_setattr+0x10c/0x280 net/netlabel/netlabel_kapi.c:1177 selinux_netlbl_socket_connect_helper+0xd3/0x1b0 security/selinux/netlabel.c:569 selinux_netlbl_socket_connect_locked security/selinux/netlabel.c:597 [inline] selinux_netlbl_socket_connect+0xb6/0x100 security/selinux/netlabel.c:615 selinux_socket_connect+0x5f/0x80 security/selinux/hooks.c:4931 security_socket_connect+0x50/0xa0 security/security.c:4598 __sys_connect_file+0xa4/0x190 net/socket.c:2067 __sys_connect+0x12c/0x170 net/socket.c:2088 __do_sys_connect net/socket.c:2098 [inline] __se_sys_connect net/socket.c:2095 [inline] __x64_sys_connect+0x73/0xb0 net/socket.c:2095 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f901b61a12dCode: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f9019bd6fa8 EFLAGS: 00000246 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 00007f901b925fa0 RCX: 00007f901b61a12dRDX: 000000000000001c RSI: 0000200000000140 RDI: 0000000000000003RBP: 00007f901b701505 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f901b5b62a0 R15: 00007f9019bb7000 Modules linked in:
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: bcm: rpi: Add NULL check in raspberrypi_clk_register()devm_kasprintf() returns NULL when memory allocation fails. Currently,raspberrypi_clk_register() does not check for this case, which resultsin a NULL pointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: Revert atm_account_tx() if copy_from_iter_full() fails.In vcc_sendmsg(), we account skb->truesize to sk->sk_wmem_alloc byatm_account_tx().It is expected to be reverted by atm_pop_raw() later called byvcc->dev->ops->send(vcc, skb).However, vcc_sendmsg() misses the same revert when copy_from_iter_full()fails, and then we will leak a socket.Let's factorise the revert part as atm_return_tx() and call it inthe failure path.Note that the corresponding sk_wmem_alloc operation can be found inalloc_tx() as of the blamed commit. $ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: Make sure modelist not set on unregistered consoleIt looks like attempting to write to the "store_modes" sysfs node willrun afoul of unregistered consoles:UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28index -1 is out of range for type 'fb_info *[32]'... fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113 dev_attr_store+0x55/0x80 drivers/base/core.c:2439static struct fb_info *fbcon_registered_fb[FB_MAX];...static signed char con2fb_map[MAX_NR_CONSOLES];...static struct fb_info *fbcon_info_from_console(int console)... return fbcon_registered_fb[con2fb_map[console]];If con2fb_map contains a -1 things go wrong here. Instead, return NULL,as callers of fbcon_info_from_console() are trying to compare againstexisting "info" pointers, so error handling should kick in correctly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAXOtherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()when resizing hashtable because __GFP_NOWARN is unset.Similar to: b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem()bpf_map_lookup_percpu_elem() helper is also available for sleepable bpfprogram. When BPF JIT is disabled or under 32-bit host,bpf_map_lookup_percpu_elem() will not be inlined. Using it in asleepable bpf program will trigger the warning inbpf_map_lookup_percpu_elem(), because the bpf program only holdsrcu_read_lock_trace lock. Therefore, add the missed check.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: add NULL check in automount_fullpathpage is checked for null in __build_path_from_dentry_optional_prefixwhen tcon->origin_fullpath is not set. However, the check is missing whenit is set.Add a check to prevent a potential NULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:configfs-tsm-report: Fix NULL dereference of tsm_opsUnlike sysfs, the lifetime of configfs objects is controlled byuserspace. There is no mechanism for the kernel to find and delete allcreated config-items. Instead, the configfs-tsm-report mechanism has anexpectation that tsm_unregister() can happen at any time and causeestablished config-item access to start failing.That expectation is not fully satisfied. While tsm_report_read(),tsm_report_{is,is_bin}_visible(), and tsm_report_make_item() safely failif tsm_ops have been unregistered, tsm_report_privlevel_store()tsm_report_provider_show() fail to check for ops registration. Add themissing checks for tsm_ops having been removed.Now, in supporting the ability for tsm_unregister() to always succeed,it leaves the problem of what to do with lingering config-items. Theexpectation is that the admin that arranges for the ->remove() (unbind)of the ${tsm_arch}-guest driver is also responsible for deletion of allopen config-items. Until that deletion happens, ->probe() (reload /bind) of the ${tsm_arch}-guest driver fails.This allows for emergency shutdown / revocation of attestationinterfaces, and requires coordinated restart.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_varIf fb_add_videomode() in fb_set_var() fails to allocate memory forfb_videomode, later it may lead to a null-ptr dereference infb_videomode_to_var(), as the fb_info is registered while not having themode in modelist that is expected to be there, i.e. the one that isdescribed in fb_info->var.================================================================general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1================================================================The reason is that fb_info->var is being modified in fb_set_var(), andthen fb_videomode_to_var() is called. If it fails to add the mode tofb_info->modelist, fb_set_var() returns error, but does not restore theold value of fb_info->var. Restore fb_info->var on failure the same wayit is done earlier in the function.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Cleanup after an allocation errorWhen allocation failures are not cleaned up by the driver, furtherallocation errors will be false-positives, which will cause buffers toremain uninitialized and cause NULL pointer dereferences.Ensure proper cleanup of failed allocations to prevent these issues.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt: properly flush XDP redirect listsWe encountered following crash when testing a XDP_REDIRECT featurein production:[56251.579676] list_add corruption. next->prev should be prev (ffff93120dd40f30), but was ffffb301ef3a6740. (next=ffff93120dd40f30).[56251.601413] ------------[ cut here ]------------[56251.611357] kernel BUG at lib/list_debug.c:29![56251.621082] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI[56251.632073] CPU: 111 UID: 0 PID: 0 Comm: swapper/111 Kdump: loaded Tainted: P O 6.12.33-cloudflare-2025.6.3 #1[56251.653155] Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE[56251.663877] Hardware name: MiTAC GC68B-B8032-G11P6-GPU/S8032GM-HE-CFR, BIOS V7.020.B10-sig 01/22/2025[56251.682626] RIP: 0010:__list_add_valid_or_report+0x4b/0xa0[56251.693203] Code: 0e 48 c7 c7 68 e7 d9 97 e8 42 16 fe ff 0f 0b 48 8b 52 08 48 39 c2 74 14 48 89 f1 48 c7 c7 90 e7 d9 97 48 89 c6 e8 25 16 fe ff <0f> 0b 4c 8b 02 49 39 f0 74 14 48 89 d1 48 c7 c7 e8 e7 d9 97 4c 89[56251.725811] RSP: 0018:ffff93120dd40b80 EFLAGS: 00010246[56251.736094] RAX: 0000000000000075 RBX: ffffb301e6bba9d8 RCX: 0000000000000000[56251.748260] RDX: 0000000000000000 RSI: ffff9149afda0b80 RDI: ffff9149afda0b80[56251.760349] RBP: ffff9131e49c8000 R08: 0000000000000000 R09: ffff93120dd40a18[56251.772382] R10: ffff9159cf2ce1a8 R11: 0000000000000003 R12: ffff911a80850000[56251.784364] R13: ffff93120fbc7000 R14: 0000000000000010 R15: ffff9139e7510e40[56251.796278] FS: 0000000000000000(0000) GS:ffff9149afd80000(0000) knlGS:0000000000000000[56251.809133] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[56251.819561] CR2: 00007f5e85e6f300 CR3: 00000038b85e2006 CR4: 0000000000770ef0[56251.831365] PKRU: 55555554[56251.838653] Call Trace:[56251.845560] [56251.851943] cpu_map_enqueue.cold+0x5/0xa[56251.860243] xdp_do_redirect+0x2d9/0x480[56251.868388] bnxt_rx_xdp+0x1d8/0x4c0 [bnxt_en][56251.877028] bnxt_rx_pkt+0x5f7/0x19b0 [bnxt_en][56251.885665] ? cpu_max_write+0x1e/0x100[56251.893510] ? srso_alias_return_thunk+0x5/0xfbef5[56251.902276] __bnxt_poll_work+0x190/0x340 [bnxt_en][56251.911058] bnxt_poll+0xab/0x1b0 [bnxt_en][56251.919041] ? srso_alias_return_thunk+0x5/0xfbef5[56251.927568] ? srso_alias_return_thunk+0x5/0xfbef5[56251.935958] ? srso_alias_return_thunk+0x5/0xfbef5[56251.944250] __napi_poll+0x2b/0x160[56251.951155] bpf_trampoline_6442548651+0x79/0x123[56251.959262] __napi_poll+0x5/0x160[56251.966037] net_rx_action+0x3d2/0x880[56251.973133] ? srso_alias_return_thunk+0x5/0xfbef5[56251.981265] ? srso_alias_return_thunk+0x5/0xfbef5[56251.989262] ? __hrtimer_run_queues+0x162/0x2a0[56251.996967] ? srso_alias_return_thunk+0x5/0xfbef5[56252.004875] ? srso_alias_return_thunk+0x5/0xfbef5[56252.012673] ? bnxt_msix+0x62/0x70 [bnxt_en][56252.019903] handle_softirqs+0xcf/0x270[56252.026650] irq_exit_rcu+0x67/0x90[56252.032933] common_interrupt+0x85/0xa0[56252.039498] [56252.044246] [56252.048935] asm_common_interrupt+0x26/0x40[56252.055727] RIP: 0010:cpuidle_enter_state+0xb8/0x420[56252.063305] Code: dc 01 00 00 e8 f9 79 3b ff e8 64 f7 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 a5 32 3a ff 45 84 ff 0f 85 ae 01 00 00 fb 45 85 f6 <0f> 88 88 01 00 00 48 8b 04 24 49 63 ce 4c 89 ea 48 6b f1 68 48 29[56252.088911] RSP: 0018:ffff93120c97fe98 EFLAGS: 00000202[56252.096912] RAX: ffff9149afd80000 RBX: ffff9141d3a72800 RCX: 0000000000000000[56252.106844] RDX: 00003329176c6b98 RSI: ffffffe36db3fdc7 RDI: 0000000000000000[56252.116733] RBP: 0000000000000002 R08: 0000000000000002 R09: 000000000000004e[56252.126652] R10: ffff9149afdb30c4 R11: 071c71c71c71c71c R12: ffffffff985ff860[56252.136637] R13: 00003329176c6b98 R14: 0000000000000002 R15: 0000000000000000[56252.146667] ? cpuidle_enter_state+0xab/0x420[56252.153909] cpuidle_enter+0x2d/0x40[56252.160360] do_idle+0x176/0x1c0[56252.166456---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: prevent NULL deref in clip_push()Blamed commit missed that vcc_destroy_socket() callsclip_push() with a NULL skb.If clip_devs is NULL, clip_push() then crashes when readingskb->truesize.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:lib/group_cpus: fix NULL pointer dereference from group_cpus_evenly()While testing null_blk with configfs, echo 0 > poll_queues will triggerfollowing panic:BUG: kernel NULL pointer dereference, address: 0000000000000010Oops: Oops: 0000 [#1] SMP NOPTICPU: 27 UID: 0 PID: 920 Comm: bash Not tainted 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014RIP: 0010:__bitmap_or+0x48/0x70Call Trace: __group_cpus_evenly+0x822/0x8c0 group_cpus_evenly+0x2d9/0x490 blk_mq_map_queues+0x1e/0x110 null_map_queues+0xc9/0x170 [null_blk] blk_mq_update_queue_map+0xdb/0x160 blk_mq_update_nr_hw_queues+0x22b/0x560 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_poll_queues_store+0xa4/0x130 [null_blk] configfs_write_iter+0x109/0x1d0 vfs_write+0x26e/0x6f0 ksys_write+0x79/0x180 __x64_sys_write+0x1d/0x30 x64_sys_call+0x45c4/0x45f0 do_syscall_64+0xa5/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7eRoot cause is that numgrps is set to 0, and ZERO_SIZE_PTR is returned fromkcalloc(), and later ZERO_SIZE_PTR will be deferenced.Fix the problem by checking numgrps first in group_cpus_evenly(), andreturn NULL directly if numgrps is zero.[yukuai3@huawei.com: also fix the non-SMP version]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: codecs: wcd9335: Fix missing free of regulator suppliesDriver gets and enables all regulator supplies in probe path(wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanupin final error paths and in unbind (missing remove() callback). Thisleads to leaked memory and unbalanced regulator enable count duringprobe errors or unbind.Fix this by converting entire code into devm_regulator_bulk_get_enable()which also greatly simplifies the code.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bcache: fix NULL pointer in cache_set_flush()1. LINE#1794 - LINE#1887 is some codes about function of bch_cache_set_alloc().2. LINE#2078 - LINE#2142 is some codes about function of register_cache_set().3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098. 1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb) 1795 { ... 1860 if (!(c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL)) || 1861 mempool_init_slab_pool(&c->search, 32, bch_search_cache) || 1862 mempool_init_kmalloc_pool(&c->bio_meta, 2, 1863 sizeof(struct bbio) + sizeof(struct bio_vec) * 1864 bucket_pages(c)) || 1865 mempool_init_kmalloc_pool(&c->fill_iter, 1, iter_size) || 1866 bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio), 1867 BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) || 1868 !(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) || 1869 !(c->moving_gc_wq = alloc_workqueue("bcache_gc", 1870 WQ_MEM_RECLAIM, 0)) || 1871 bch_journal_alloc(c) || 1872 bch_btree_cache_alloc(c) || 1873 bch_open_buckets_alloc(c) || 1874 bch_bset_sort_state_init(&c->sort, ilog2(c->btree_pages))) 1875 goto err; ^^^^^^^^ 1876 ... 1883 return c; 1884 err: 1885 bch_cache_set_unregister(c); ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1886 return NULL; 1887 } ... 2078 static const char *register_cache_set(struct cache *ca) 2079 { ... 2098 c = bch_cache_set_alloc(&ca->sb); 2099 if (!c) 2100 return err; ^^^^^^^^^^ ... 2128 ca->set = c; 2129 ca->set->cache[ca->sb.nr_this_dev] = ca; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... 2138 return NULL; 2139 err: 2140 bch_cache_set_unregister(c); 2141 return err; 2142 }(1) If LINE#1860 - LINE#1874 is true, then do 'goto err'(LINE#1875) and call bch_cache_set_unregister()(LINE#1885).(2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return.(3) As (2) has returned, LINE#2128 - LINE#2129 would do *not* give the value to c->cache[], it means that c->cache[] is NULL.LINE#1624 - LINE#1665 is some codes about function of cache_set_flush().As (1), in LINE#1885 callbch_cache_set_unregister()---> bch_cache_set_stop() ---> closure_queue() -.-> cache_set_flush() (as below LINE#1624) 1624 static void cache_set_flush(struct closure *cl) 1625 { ... 1654 for_each_cache(ca, c, i) 1655 if (ca->alloc_thread) ^^ 1656 kthread_stop(ca->alloc_thread); ... 1665 }(4) In LINE#1655 ca is NULL(see (3)) in cache_set_flush() then the kernel crash occurred as below:[ 846.712887] bcache: register_cache() error drbd6: cannot allocate memory[ 846.713242] bcache: register_bcache() error : failed to register device[ 846.713336] bcache: cache_set_free() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered[ 846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8[ 846.714790] PGD 0 P4D 0[ 846.715129] Oops: 0000 [#1] SMP PTI[ 846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G OE --------- - - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1[ 846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018[ 846.716451] Workqueue: events cache_set_flush [bcache][ 846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache][ 846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 <48> 8b b8 f8 09 00 0---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: sanitize request list handlingValidate the request in nvme_tcp_handle_r2t() to ensure it's not part ofany list, otherwise a malicious R2T PDU might inject a loop in requestlist processing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: b53: do not enable EEE on bcm63xxBCM63xx internal switches do not support EEE, but provide multiple RGMIIports where external PHYs may be connected. If one of these PHYs are EEEcapable, we may try to enable EEE for the MACs, which then hangs thesystem on access of the (non-existent) EEE registers.Fix this by checking if the switch actually supports EEE beforeattempting to configure it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Do not include stack ptr register in precision backtracking bookkeepingYi Lai reported an issue ([1]) where the following warning appearsin kernel dmesg: [ 60.643604] verifier backtracking bug [ 60.643635] WARNING: CPU: 10 PID: 2315 at kernel/bpf/verifier.c:4302 __mark_chain_precision+0x3a6c/0x3e10 [ 60.648428] Modules linked in: bpf_testmod(OE) [ 60.650471] CPU: 10 UID: 0 PID: 2315 Comm: test_progs Tainted: G OE 6.15.0-rc4-gef11287f8289-dirty #327 PREEMPT(full) [ 60.654385] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 60.656682] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 60.660475] RIP: 0010:__mark_chain_precision+0x3a6c/0x3e10 [ 60.662814] Code: 5a 30 84 89 ea e8 c4 d9 01 00 80 3d 3e 7d d8 04 00 0f 85 60 fa ff ff c6 05 31 7d d8 04 01 48 c7 c7 00 58 30 84 e8 c4 06 a5 ff <0f> 0b e9 46 fa ff ff 48 ... [ 60.668720] RSP: 0018:ffff888116cc7298 EFLAGS: 00010246 [ 60.671075] RAX: 54d70e82dfd31900 RBX: ffff888115b65e20 RCX: 0000000000000000 [ 60.673659] RDX: 0000000000000001 RSI: 0000000000000004 RDI: 00000000ffffffff [ 60.676241] RBP: 0000000000000400 R08: ffff8881f6f23bd3 R09: 1ffff1103ede477a [ 60.678787] R10: dffffc0000000000 R11: ffffed103ede477b R12: ffff888115b60ae8 [ 60.681420] R13: 1ffff11022b6cbc4 R14: 00000000fffffff2 R15: 0000000000000001 [ 60.684030] FS: 00007fc2aedd80c0(0000) GS:ffff88826fa8a000(0000) knlGS:0000000000000000 [ 60.686837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 60.689027] CR2: 000056325369e000 CR3: 000000011088b002 CR4: 0000000000370ef0 [ 60.691623] Call Trace: [ 60.692821] [ 60.693960] ? __pfx_verbose+0x10/0x10 [ 60.695656] ? __pfx_disasm_kfunc_name+0x10/0x10 [ 60.697495] check_cond_jmp_op+0x16f7/0x39b0 [ 60.699237] do_check+0x58fa/0xab10 ...Further analysis shows the warning is at line 4302 as below: 4294 /* static subprog call instruction, which 4295 * means that we are exiting current subprog, 4296 * so only r1-r5 could be still requested as 4297 * precise, r0 and r6-r10 or any stack slot in 4298 * the current frame should be zero by now 4299 */ 4300 if (bt_reg_mask(bt) & ~BPF_REGMASK_ARGS) { 4301 verbose(env, "BUG regs %x\n", bt_reg_mask(bt)); 4302 WARN_ONCE(1, "verifier backtracking bug"); 4303 return -EFAULT; 4304 }With the below test (also in the next patch): __used __naked static void __bpf_jmp_r10(void) { asm volatile ( "r2 = 2314885393468386424 ll;" "goto +0;" "if r2 <= r10 goto +3;" "if r1 >= -1835016 goto +0;" "if r2 <= 8 goto +0;" "if r3 <= 0 goto +0;" "exit;" ::: __clobber_all); } SEC("?raw_tp") __naked void bpf_jmp_r10(void) { asm volatile ( "r3 = 0 ll;" "call __bpf_jmp_r10;" "r0 = 0;" "exit;" ::: __clobber_all); }The following is the verifier failure log: 0: (18) r3 = 0x0 ; R3_w=0 2: (85) call pc+2 caller: R10=fp0 callee: frame1: R1=ctx() R3_w=0 R10=fp0 5: frame1: R1=ctx() R3_w=0 R10=fp0 ; asm volatile (" \ @ verifier_precision.c:184 5: (18) r2 = 0x20202000256c6c78 ; frame1: R2_w=0x20202000256c6c78 7: (05) goto pc+0 8: (bd) if r2 <= r10 goto pc+3 ; frame1: R2_w=0x20202000256c6c78 R10=fp0 9: (35) if r1 >= 0xffe3fff8 goto pc+0 ; frame1: R1=ctx() 10: (b5) if r2 <= 0x8 goto pc+0 mark_precise: frame1: last_idx 10 first_idx 0 subseq_idx -1 mark_precise: frame1: regs=r2 stack= before 9: (35) if r1 >= 0xffe3fff8 goto pc+0 mark_precise: frame1: regs=r2 stack= before 8: (bd) if r2 <= r10 goto pc+3 mark_preci---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Avoid __bpf_prog_ret0_warn when jit failssyzkaller reported an issue:WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357Modules linked in:CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 6.15.0-rc4-syzkaller-00040-g8bac8898fe39RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357Call Trace: bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] cls_bpf_classify+0x74a/0x1110 net/sched/cls_bpf.c:105 ...When creating bpf program, 'fp->jit_requested' depends on bpf_jit_enable.This issue is triggered because of CONFIG_BPF_JIT_ALWAYS_ON is not setand bpf_jit_enable is set to 1, causing the arch to attempt JIT the prog,but jit failed due to FAULT_INJECTION. As a result, incorrectlytreats the program as valid, when the program runs it calls`__bpf_prog_ret0_warn` and triggers the WARN_ON_ONCE(1).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hisi_acc_vfio_pci: bugfix live migration function without VF device driverIf the VF device driver is not loaded in the Guest OS and we attempt toperform device data migration, the address of the migrated data willbe NULL.The live migration recovery operation on the destination side willaccess a null address value, which will cause access errors.Therefore, live migration of VMs without added VF device driversdoes not require device data migration.In addition, when the queue address data obtained by the destinationis empty, device queue recovery processing will not be performed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix WARN() in get_bpf_raw_tp_regssyzkaller reported an issue:WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861Modules linked in:CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4cRDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47Tracepoint like trace_mmap_lock_acquire_returned may cause nested callas the corner case show above, which will be resolved with more generalmethod in the future. As a result, WARN_ON_ONCE will be triggered. AsAlexei suggested, remove the WARN_ON_ONCE first.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix NULL pointer deference on eir_get_service_dataThe len parameter is considered optional so it can be NULL so it cannotbe used for skipping to next entry of EIR_SERVICE_DATA.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()There is no disagreement that we should check both ptp->is_virtual_clockand ptp->n_vclocks to check if the ptp virtual clock is in use.However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks inptp_vclock_in_use(), we observe a recursive lock in the call tracestarting from n_vclocks_store().============================================WARNING: possible recursive locking detected6.15.0-rc6 #1 Not tainted--------------------------------------------syz.0.1540/13807 is trying to acquire lock:ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline]ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415but task is already holding lock:ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux); *** DEADLOCK ***....============================================The best way to solve this is to remove the logic that checksptp->n_vclocks in ptp_vclock_in_use().The reason why this is appropriate is that any path that usesptp->n_vclocks must unconditionally check if ptp->n_vclocks is greaterthan 0 before unregistering vclocks, and all functions are alreadywritten this way. And in the function that uses ptp->n_vclocks, wealready get ptp->n_vclocks_mux before unregistering vclocks.Therefore, we need to remove the redundant check for ptp->n_vclocks inptp_vclock_in_use() to prevent recursive locking.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc: fix double-free on mc_devThe blamed commit tried to simplify how the deallocations are done but,in the process, introduced a double-free on the mc_dev variable.In case the MC device is a DPRC, a new mc_bus is allocated and themc_dev variable is just a reference to one of its fields. In thiscircumstance, on the error path only the mc_bus should be freed.This commit introduces back the following checkpatch warning which is afalse-positive.WARNING: kfree(NULL) is safe and this check is probably not required+ if (mc_bus)+ kfree(mc_bus);
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_tableThe function atomctrl_initialize_mc_reg_table() andatomctrl_initialize_mc_reg_table_v2_2() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table()fails to retrieve vram_info, it returns NULL which is laterdereferenced.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:aoe: clean device rq_list in aoedev_downdev()An aoe device's rq_list contains accepted block requests that arewaiting to be transmitted to the aoe target. This queue was added aspart of the conversion to blk_mq. However, the queue was not cleaned outwhen an aoe device is downed which caused blk_mq_freeze_queue() to sleepindefinitely waiting for those requests to complete, causing a hang. Thisfix cleans out the queue before calling blk_mq_freeze_queue().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Use memcpy() for BIOS versionThe strlcat() with FORTIFY support is triggering a panic because itthinks the target buffer will overflow although the correct targetbuffer size is passed in.Anyway, instead of memset() with 0 followed by a strlcat(), just usememcpy() and ensure that the resulting buffer is NULL terminated.BIOSVersion is only used for the lpfc_printf_log() which expects aproperly terminated string.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata()Since handle->h_transaction may be a NULL pointer, so we should change itto call is_handle_aborted(handle) first before dereferencing it.And the following data-race was reported in my fuzzer:==================================================================BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadatawrite to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1: jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103....read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0: jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103....value changed: 0x00000000 -> 0x00000001==================================================================This issue is caused by missing data-race annotation for jh->b_modified.Therefore, the missing annotation needs to be added.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: fix acpi parse and parseext cache leaksACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5I'm Seunghun Han, and I work for National Security Research Institute ofSouth Korea.I have been doing a research on ACPI and found an ACPI cache leak in ACPIearly abort cases.Boot log of ACPI cache leak is as follows:[ 0.352414] ACPI: Added _OSI(Module Device)[ 0.353182] ACPI: Added _OSI(Processor Device)[ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions)[ 0.353182] ACPI: Added _OSI(Processor Aggregator Device)[ 0.356028] ACPI: Unable to start the ACPI Interpreter[ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)[ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects[ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W4.12.0-rc4-next-20170608+ #10[ 0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOSvirtual_box 12/01/2006[ 0.361873] Call Trace:[ 0.362243] ? dump_stack+0x5c/0x81[ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0[ 0.362944] ? acpi_sleep_proc_init+0x27/0x27[ 0.363296] ? acpi_os_delete_cache+0xa/0x10[ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b[ 0.364000] ? acpi_terminate+0xa/0x14[ 0.364000] ? acpi_init+0x2af/0x34f[ 0.364000] ? __class_create+0x4c/0x80[ 0.364000] ? video_setup+0x7f/0x7f[ 0.364000] ? acpi_sleep_proc_init+0x27/0x27[ 0.364000] ? do_one_initcall+0x4e/0x1a0[ 0.364000] ? kernel_init_freeable+0x189/0x20a[ 0.364000] ? rest_init+0xc0/0xc0[ 0.364000] ? kernel_init+0xa/0x100[ 0.364000] ? ret_from_fork+0x25/0x30I analyzed this memory leak in detail. I found that “Acpi-State” cache and“Acpi-Parse” cache were merged because the size of cache objects was sameslab cache size.I finally found “Acpi-Parse” cache and “Acpi-parse_ext” cache were leakedusing SLAB_NEVER_MERGE flag in kmem_cache_create() function.Real ACPI cache leak point is as follows:[ 0.360101] ACPI: Added _OSI(Module Device)[ 0.360101] ACPI: Added _OSI(Processor Device)[ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions)[ 0.361043] ACPI: Added _OSI(Processor Aggregator Device)[ 0.364016] ACPI: Unable to start the ACPI Interpreter[ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)[ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects[ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W4.12.0-rc4-next-20170608+ #8[ 0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOSvirtual_box 12/01/2006[ 0.372000] Call Trace:[ 0.372000] ? dump_stack+0x5c/0x81[ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0[ 0.372000] ? acpi_sleep_proc_init+0x27/0x27[ 0.372000] ? acpi_os_delete_cache+0xa/0x10[ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b[ 0.372000] ? acpi_terminate+0xa/0x14[ 0.372000] ? acpi_init+0x2af/0x34f[ 0.372000] ? __class_create+0x4c/0x80[ 0.372000] ? video_setup+0x7f/0x7f[ 0.372000] ? acpi_sleep_proc_init+0x27/0x27[ 0.372000] ? do_one_initcall+0x4e/0x1a0[ 0.372000] ? kernel_init_freeable+0x189/0x20a[ 0.372000] ? rest_init+0xc0/0xc0[ 0.372000] ? kernel_init+0xa/0x100[ 0.372000] ? ret_from_fork+0x25/0x30[ 0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects[ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W4.12.0-rc4-next-20170608+ #8[ 0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOSvirtual_box 12/01/2006[ 0.392000] Call Trace:[ 0.392000] ? dump_stack+0x5c/0x81[ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0[ 0.392000] ? acpi_sleep_proc_init+0x27/0x27[ 0.392000] ? acpi_os_delete_cache+0xa/0x10[ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b[ 0.392000] ? acpi_terminate+0xa/0x14[ 0.392000] ? acpi_init+0x2af/0x3---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/mm: Fix in_atomic() handling in do_secure_storage_access()Kernel user spaces accesses to not exported pages in atomic contextincorrectly try to resolve the page fault.With debug options enabled call traces like this can be seen:BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39preempt_count: 1, expected: 0RCU nest depth: 0, expected: 0INFO: lockdep is turned off.Preemption disabled at:[<00000383ea47cfa2>] copy_page_from_iter_atomic+0xa2/0x8a0CPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39Tainted: G W 6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPTTainted: [W]=WARNHardware name: IBM 3931 A01 703 (LPAR)Call Trace: [<00000383e990d282>] dump_stack_lvl+0xa2/0xe8 [<00000383e99bf152>] __might_resched+0x292/0x2d0 [<00000383eaa7c374>] down_read+0x34/0x2d0 [<00000383e99432f8>] do_secure_storage_access+0x108/0x360 [<00000383eaa724b0>] __do_pgm_check+0x130/0x220 [<00000383eaa842e4>] pgm_check_handler+0x114/0x160 [<00000383ea47d028>] copy_page_from_iter_atomic+0x128/0x8a0([<00000383ea47d016>] copy_page_from_iter_atomic+0x116/0x8a0) [<00000383e9c45eae>] generic_perform_write+0x16e/0x310 [<00000383e9eb87f4>] ext4_buffered_write_iter+0x84/0x160 [<00000383e9da0de4>] vfs_write+0x1c4/0x460 [<00000383e9da123c>] ksys_write+0x7c/0x100 [<00000383eaa7284e>] __do_syscall+0x15e/0x280 [<00000383eaa8417e>] system_call+0x6e/0x90INFO: lockdep is turned off.It is not allowed to take the mmap_lock while in atomic context. Thereforehandle such a secure storage access fault as if the accessed page is notmapped: the uaccess function will return -EFAULT, and the caller has todeal with this. Usually this means that the access is retried in processcontext, which allows to resolve the page fault (or in this case export thepage).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null pointer check for get_first_active_display()The function mod_hdcp_hdcp1_enable_encryption() calls the functionget_first_active_display(), but does not check its return value.The return value is a null pointer if the display list is empty.This will lead to a null pointer dereference inmod_hdcp_hdcp2_enable_encryption().Add a null pointer check for get_first_active_display() and returnMOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/tegra: Fix a possible null pointer dereferenceIn tegra_crtc_reset(), new memory is allocated with kzalloc(), butno check is performed. Before calling __drm_atomic_helper_crtc_reset,state should be checked to prevent possible null pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before usingRunning IDXD workloads in a container with the /dev directory mounted cantrigger a call trace or even a kernel panic when the parent process of thecontainer is terminated.This issue occurs because, under certain configurations, Docker does notproperly propagate the mount replica back to the original mount point.In this case, when the user driver detaches, the WQ is destroyed but itstill calls destroy_workqueue() attempting to completes all pending work.It's necessary to check wq->wq and skip the drain if it no longer exists.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Disable interrupts before resetting the GPUCurrently, an interrupt can be triggered during a GPU reset, which canlead to GPU hangs and NULL pointer dereference in an interrupt contextas shown in the following trace: [ 314.035040] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0 [ 314.043822] Mem abort info: [ 314.046606] ESR = 0x0000000096000005 [ 314.050347] EC = 0x25: DABT (current EL), IL = 32 bits [ 314.055651] SET = 0, FnV = 0 [ 314.058695] EA = 0, S1PTW = 0 [ 314.061826] FSC = 0x05: level 1 translation fault [ 314.066694] Data abort info: [ 314.069564] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 314.075039] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 314.080080] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 314.085382] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000102728000 [ 314.091814] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 314.100511] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 314.106770] Modules linked in: v3d i2c_brcmstb vc4 snd_soc_hdmi_codec gpu_sched drm_shmem_helper drm_display_helper cec drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 314.129654] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1 Debian 1:6.12.25-1+rpt1 [ 314.139388] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) [ 314.145211] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 314.152165] pc : v3d_irq+0xec/0x2e0 [v3d] [ 314.156187] lr : v3d_irq+0xe0/0x2e0 [v3d] [ 314.160198] sp : ffffffc080003ea0 [ 314.163502] x29: ffffffc080003ea0 x28: ffffffec1f184980 x27: 021202b000000000 [ 314.170633] x26: ffffffec1f17f630 x25: ffffff8101372000 x24: ffffffec1f17d9f0 [ 314.177764] x23: 000000000000002a x22: 000000000000002a x21: ffffff8103252000 [ 314.184895] x20: 0000000000000001 x19: 00000000deadbeef x18: 0000000000000000 [ 314.192026] x17: ffffff94e51d2000 x16: ffffffec1dac3cb0 x15: c306000000000000 [ 314.199156] x14: 0000000000000000 x13: b2fc982e03cc5168 x12: 0000000000000001 [ 314.206286] x11: ffffff8103f8bcc0 x10: ffffffec1f196868 x9 : ffffffec1dac3874 [ 314.213416] x8 : 0000000000000000 x7 : 0000000000042a3a x6 : ffffff810017a180 [ 314.220547] x5 : ffffffec1ebad400 x4 : ffffffec1ebad320 x3 : 00000000000bebeb [ 314.227677] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 314.234807] Call trace: [ 314.237243] v3d_irq+0xec/0x2e0 [v3d] [ 314.240906] __handle_irq_event_percpu+0x58/0x218 [ 314.245609] handle_irq_event+0x54/0xb8 [ 314.249439] handle_fasteoi_irq+0xac/0x240 [ 314.253527] handle_irq_desc+0x48/0x68 [ 314.257269] generic_handle_domain_irq+0x24/0x38 [ 314.261879] gic_handle_irq+0x48/0xd8 [ 314.265533] call_on_irq_stack+0x24/0x58 [ 314.269448] do_interrupt_handler+0x88/0x98 [ 314.273624] el1_interrupt+0x34/0x68 [ 314.277193] el1h_64_irq_handler+0x18/0x28 [ 314.281281] el1h_64_irq+0x64/0x68 [ 314.284673] default_idle_call+0x3c/0x168 [ 314.288675] do_idle+0x1fc/0x230 [ 314.291895] cpu_startup_entry+0x3c/0x50 [ 314.295810] rest_init+0xe4/0xf0 [ 314.299030] start_kernel+0x5e8/0x790 [ 314.302684] __primary_switched+0x80/0x90 [ 314.306691] Code: 940029eb 360ffc13 f9442ea0 52800001 (f9406017) [ 314.312775] ---[ end trace 0000000000000000 ]--- [ 314.317384] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 314.324249] SMP: stopping secondary CPUs [ 314.328167] Kernel Offset: 0x2b9da00000 from 0xffffffc080000000 [ 314.334076] PHYS_OFFSET: 0x0 [ 314.336946] CPU features: 0x08,00002013,c0200000,0200421b [ 314.342337] Memory Limit: none [ 314.345382] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---Before resetting the G---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Refuse to evaluate a method if arguments are missingAs reported in [1], a platform firmware update that increased the numberof method parameters and forgot to update a least one of its callers,caused ACPICA to crash due to use-after-free.Since this a result of a clear AML issue that arguably cannot be fixedup by the interpreter (it cannot produce missing data out of thin air),address it by making ACPICA refuse to evaluate a method if the callerattempts to pass fewer arguments than expected to it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gt: Fix timeline left held on VMA alloc errorThe following error has been reported sporadically by CI when a testunbinds the i915 driver on a ring submission platform:<4> [239.330153] ------------[ cut here ]------------<4> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count)<4> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915]...<4> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915]...<4> [239.330942] Call Trace:<4> [239.330944] <4> [239.330949] i915_driver_late_release+0x2b/0xa0 [i915]<4> [239.331202] i915_driver_release+0x86/0xa0 [i915]<4> [239.331482] devm_drm_dev_init_release+0x61/0x90<4> [239.331494] devm_action_release+0x15/0x30<4> [239.331504] release_nodes+0x3d/0x120<4> [239.331517] devres_release_all+0x96/0xd0<4> [239.331533] device_unbind_cleanup+0x12/0x80<4> [239.331543] device_release_driver_internal+0x23a/0x280<4> [239.331550] ? bus_find_device+0xa5/0xe0<4> [239.331563] device_driver_detach+0x14/0x20...<4> [357.719679] ---[ end trace 0000000000000000 ]---If the test also unloads the i915 module then that's followed with:<3> [357.787478] =============================================================================<3> [357.788006] BUG i915_vma (Tainted: G U W N ): Objects remaining on __kmem_cache_shutdown()<3> [357.788031] -----------------------------------------------------------------------------<3> [357.788204] Object 0xffff888109e7f480 @offset=29824<3> [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244<4> [357.788994] i915_vma_instance+0xee/0xc10 [i915]<4> [357.789290] init_status_page+0x7b/0x420 [i915]<4> [357.789532] intel_engines_init+0x1d8/0x980 [i915]<4> [357.789772] intel_gt_init+0x175/0x450 [i915]<4> [357.790014] i915_gem_init+0x113/0x340 [i915]<4> [357.790281] i915_driver_probe+0x847/0xed0 [i915]<4> [357.790504] i915_pci_probe+0xe6/0x220 [i915]...Closer analysis of CI results history has revealed a dependency of theerror on a few IGT tests, namely:- igt@api_intel_allocator@fork-simple-stress-signal,- igt@api_intel_allocator@two-level-inception-interruptible,- igt@gem_linear_blits@interruptible,- igt@prime_mmap_coherency@ioctl-errors,which invisibly trigger the issue, then exhibited with first driver unbindattempt.All of the above tests perform actions which are actively interrupted withsignals. Further debugging has allowed to narrow that scope down toDRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ringsubmission, in particular.If successful then that function, or its execlists or GuC submissionequivalent, is supposed to be called only once per GEM context engine,followed by raise of a flag that prevents the function from being calledagain. The function is expected to unwind its internal errors itself, soit may be safely called once more after it returns an error.In case of ring submission, the function first gets a reference to theengine's legacy timeline and then allocates a VMA. If the VMA allocationfails, e.g. when i915_vma_instance() called from inside is interruptedwith a signal, then ring_context_alloc() fails, leaving the timeline heldreferenced. On next I915_GEM_EXECBUFFER2 IOCTL, another reference to thetimeline is got, and only that last one is put on successful completion.As a consequence, the legacy timeline, with its underlying engine statuspage's VMA object, is still held and not released on driver unbind.Get the legacy timeline only after successful allocation of the contextengine's VMA.v2: Add a note on other submission methods (Krzysztof Karas): Both execlists and GuC submission use lrc_alloc() which seems free from a similar issue.(cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: convert control queue mutex to a spinlockWith VIRTCHNL2_CAP_MACFILTER enabled, the following warning is generatedon module load:[ 324.701677] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578[ 324.701684] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1582, name: NetworkManager[ 324.701689] preempt_count: 201, expected: 0[ 324.701693] RCU nest depth: 0, expected: 0[ 324.701697] 2 locks held by NetworkManager/1582:[ 324.701702] #0: ffffffff9f7be770 (rtnl_mutex){....}-{3:3}, at: rtnl_newlink+0x791/0x21e0[ 324.701730] #1: ff1100216c380368 (_xmit_ETHER){....}-{2:2}, at: __dev_open+0x3f0/0x870[ 324.701749] Preemption disabled at:[ 324.701752] [] __dev_open+0x3dd/0x870[ 324.701765] CPU: 30 UID: 0 PID: 1582 Comm: NetworkManager Not tainted 6.15.0-rc5+ #2 PREEMPT(voluntary)[ 324.701771] Hardware name: Intel Corporation M50FCP2SBSTD/M50FCP2SBSTD, BIOS SE5C741.86B.01.01.0001.2211140926 11/14/2022[ 324.701774] Call Trace:[ 324.701777] [ 324.701779] dump_stack_lvl+0x5d/0x80[ 324.701788] ? __dev_open+0x3dd/0x870[ 324.701793] __might_resched.cold+0x1ef/0x23d<..>[ 324.701818] __mutex_lock+0x113/0x1b80<..>[ 324.701917] idpf_ctlq_clean_sq+0xad/0x4b0 [idpf][ 324.701935] ? kasan_save_track+0x14/0x30[ 324.701941] idpf_mb_clean+0x143/0x380 [idpf]<..>[ 324.701991] idpf_send_mb_msg+0x111/0x720 [idpf][ 324.702009] idpf_vc_xn_exec+0x4cc/0x990 [idpf][ 324.702021] ? rcu_is_watching+0x12/0xc0[ 324.702035] idpf_add_del_mac_filters+0x3ed/0xb50 [idpf]<..>[ 324.702122] __hw_addr_sync_dev+0x1cf/0x300[ 324.702126] ? find_held_lock+0x32/0x90[ 324.702134] idpf_set_rx_mode+0x317/0x390 [idpf][ 324.702152] __dev_open+0x3f8/0x870[ 324.702159] ? __pfx___dev_open+0x10/0x10[ 324.702174] __dev_change_flags+0x443/0x650<..>[ 324.702208] netif_change_flags+0x80/0x160[ 324.702218] do_setlink.isra.0+0x16a0/0x3960<..>[ 324.702349] rtnl_newlink+0x12fd/0x21e0The sequence is as follows: rtnl_newlink()-> __dev_change_flags()-> __dev_open()-> dev_set_rx_mode() - > # disables BH and grabs "dev->addr_list_lock" idpf_set_rx_mode() -> # proceed only if VIRTCHNL2_CAP_MACFILTER is ON __dev_uc_sync() -> idpf_add_mac_filter -> idpf_add_del_mac_filters -> idpf_send_mb_msg() -> idpf_mb_clean() -> idpf_ctlq_clean_sq() # mutex_lock(cq_lock)Fix by converting cq_lock to a spinlock. All operations under the newlock are safe except freeing the DMA memory, which may use vunmap(). Fixby requesting a contiguous physical memory for the DMA mapping.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port()The function core_scsi3_decode_spec_i_port(), in its error code path,unconditionally calls core_scsi3_lunacl_undepend_item() passing thedest_se_deve pointer, which may be NULL.This can lead to a NULL pointer dereference if dest_se_deve remainsunset.SPC-3 PR SPEC_I_PT: Unable to locate dest_tpgUnable to handle kernel paging request at virtual address dfff800000000012Call trace: core_scsi3_lunacl_undepend_item+0x2c/0xf0 [target_core_mod] (P) core_scsi3_decode_spec_i_port+0x120c/0x1c30 [target_core_mod] core_scsi3_emulate_pro_register+0x6b8/0xcd8 [target_core_mod] target_scsi3_emulate_pr_out+0x56c/0x840 [target_core_mod]Fix this by adding a NULL check before callingcore_scsi3_lunacl_undepend_item()
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: return 0 size for RSS key if not supportedReturning -EOPNOTSUPP from function returning u32 is leading tocast and invalid size value as a result.-EOPNOTSUPP as a size probably will lead to allocation fail.Command: ethtool -x eth0It is visible on all devices that don't have RSS caps set.[ 136.615917] Call Trace:[ 136.615921] [ 136.615927] ? __warn+0x89/0x130[ 136.615942] ? __alloc_frozen_pages_noprof+0x322/0x330[ 136.615953] ? report_bug+0x164/0x190[ 136.615968] ? handle_bug+0x58/0x90[ 136.615979] ? exc_invalid_op+0x17/0x70[ 136.615987] ? asm_exc_invalid_op+0x1a/0x20[ 136.616001] ? rss_prepare_get.constprop.0+0xb9/0x170[ 136.616016] ? __alloc_frozen_pages_noprof+0x322/0x330[ 136.616028] __alloc_pages_noprof+0xe/0x20[ 136.616038] ___kmalloc_large_node+0x80/0x110[ 136.616072] __kmalloc_large_node_noprof+0x1d/0xa0[ 136.616081] __kmalloc_noprof+0x32c/0x4c0[ 136.616098] ? rss_prepare_get.constprop.0+0xb9/0x170[ 136.616105] rss_prepare_get.constprop.0+0xb9/0x170[ 136.616114] ethnl_default_doit+0x107/0x3d0[ 136.616131] genl_family_rcv_msg_doit+0x100/0x160[ 136.616147] genl_rcv_msg+0x1b8/0x2c0[ 136.616156] ? __pfx_ethnl_default_doit+0x10/0x10[ 136.616168] ? __pfx_genl_rcv_msg+0x10/0x10[ 136.616176] netlink_rcv_skb+0x58/0x110[ 136.616186] genl_rcv+0x28/0x40[ 136.616195] netlink_unicast+0x19b/0x290[ 136.616206] netlink_sendmsg+0x222/0x490[ 136.616215] __sys_sendto+0x1fd/0x210[ 136.616233] __x64_sys_sendto+0x24/0x30[ 136.616242] do_syscall_64+0x82/0x160[ 136.616252] ? __sys_recvmsg+0x83/0xe0[ 136.616265] ? syscall_exit_to_user_mode+0x10/0x210[ 136.616275] ? do_syscall_64+0x8e/0x160[ 136.616282] ? __count_memcg_events+0xa1/0x130[ 136.616295] ? count_memcg_events.constprop.0+0x1a/0x30[ 136.616306] ? handle_mm_fault+0xae/0x2d0[ 136.616319] ? do_user_addr_fault+0x379/0x670[ 136.616328] ? clear_bhb_loop+0x45/0xa0[ 136.616340] ? clear_bhb_loop+0x45/0xa0[ 136.616349] ? clear_bhb_loop+0x45/0xa0[ 136.616359] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 136.616369] RIP: 0033:0x7fd30ba7b047[ 136.616376] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d bd d5 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44[ 136.616381] RSP: 002b:00007ffde1796d68 EFLAGS: 00000202 ORIG_RAX: 000000000000002c[ 136.616388] RAX: ffffffffffffffda RBX: 000055d7bd89f2a0 RCX: 00007fd30ba7b047[ 136.616392] RDX: 0000000000000028 RSI: 000055d7bd89f3b0 RDI: 0000000000000003[ 136.616396] RBP: 00007ffde1796e10 R08: 00007fd30bb4e200 R09: 000000000000000c[ 136.616399] R10: 0000000000000000 R11: 0000000000000202 R12: 000055d7bd89f340[ 136.616403] R13: 000055d7bd89f3b0 R14: 000055d78943f200 R15: 0000000000000000
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath6kl: remove WARN on bad firmware inputIf the firmware gives bad input, that's nothing to do withthe driver's stack at this point etc., so the WARN_ON()doesn't add any value. Additionally, this is one of thetop syzbot reports now. Just print a message, and as anadded bonus, print the sizes too.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm: Fix a fence leak in submit error pathIn error paths, we could unref the submit without callingdrm_sched_entity_push_job(), so msm_job_free() will never getcalled. Since drm_sched_job_cleanup() will NULL out thes_fence, we can use that to detect this case.Patchwork: https://patchwork.freedesktop.org/patch/653584/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacksAfter retrieving WMI data blocks in sysfs callbacks, check for thevalidity of them before dereferencing their content.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: core: Release rproc->clean_table after rproc_attach() failsWhen rproc->state = RPROC_DETACHED is attached to remote processorthrough rproc_attach(), if rproc_handle_resources() returns failure,then the clean table should be released, otherwise the followingmemory leak will occur.unreferenced object 0xffff000086a99800 (size 1024):comm "kworker/u12:3", pid 59, jiffies 4294893670 (age 121.140s)hex dump (first 32 bytes):00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............backtrace: [<000000008bbe4ca8>] slab_post_alloc_hook+0x98/0x3fc [<000000003b8a272b>] __kmem_cache_alloc_node+0x13c/0x230 [<000000007a507c51>] __kmalloc_node_track_caller+0x5c/0x260 [<0000000037818dae>] kmemdup+0x34/0x60 [<00000000610f7f57>] rproc_boot+0x35c/0x56c [<0000000065f8871a>] rproc_add+0x124/0x17c [<00000000497416ee>] imx_rproc_probe+0x4ec/0x5d4 [<000000003bcaa37d>] platform_probe+0x68/0xd8 [<00000000771577f9>] really_probe+0x110/0x27c [<00000000531fea59>] __driver_probe_device+0x78/0x12c [<0000000080036a04>] driver_probe_device+0x3c/0x118 [<000000007e0bddcb>] __device_attach_driver+0xb8/0xf8 [<000000000cf1fa33>] bus_for_each_drv+0x84/0xe4 [<000000001a53b53e>] __device_attach+0xfc/0x18c [<00000000d1a2a32c>] device_initial_probe+0x14/0x20 [<00000000d8f8b7ae>] bus_probe_device+0xb0/0xb4 unreferenced object 0xffff0000864c9690 (size 16):
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach()When rproc->state = RPROC_DETACHED and rproc_attach() is usedto attach to the remote processor, if rproc_handle_resources()returns a failure, the resources allocated by imx_rproc_prepare()should be released, otherwise the following memory leak will occur.Since almost the same thing is done in imx_rproc_prepare() andrproc_resource_cleanup(), Function rproc_resource_cleanup() is ableto deal with empty lists so it is better to fix the "goto" statementsin rproc_attach(). replace the "unprepare_device" goto statement with"clean_up_resources" and get rid of the "unprepare_device" label.unreferenced object 0xffff0000861c5d00 (size 128):comm "kworker/u12:3", pid 59, jiffies 4294893509 (age 149.220s)hex dump (first 32 bytes):00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............backtrace: [<00000000f949fe18>] slab_post_alloc_hook+0x98/0x37c [<00000000adbfb3e7>] __kmem_cache_alloc_node+0x138/0x2e0 [<00000000521c0345>] kmalloc_trace+0x40/0x158 [<000000004e330a49>] rproc_mem_entry_init+0x60/0xf8 [<000000002815755e>] imx_rproc_prepare+0xe0/0x180 [<0000000003f61b4e>] rproc_boot+0x2ec/0x528 [<00000000e7e994ac>] rproc_add+0x124/0x17c [<0000000048594076>] imx_rproc_probe+0x4ec/0x5d4 [<00000000efc298a1>] platform_probe+0x68/0xd8 [<00000000110be6fe>] really_probe+0x110/0x27c [<00000000e245c0ae>] __driver_probe_device+0x78/0x12c [<00000000f61f6f5e>] driver_probe_device+0x3c/0x118 [<00000000a7874938>] __device_attach_driver+0xb8/0xf8 [<0000000065319e69>] bus_for_each_drv+0x84/0xe4 [<00000000db3eb243>] __device_attach+0xfc/0x18c [<0000000072e4e1a4>] device_initial_probe+0x14/0x20
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: carl9170: do not ping device which has failed to load firmwareSyzkaller reports [1, 2] crashes caused by an attempts to pingthe device which has failed to load firmware. Since such a devicedoesn't pass 'ieee80211_register_hw()', an internal workqueuemanaged by 'ieee80211_queue_work()' is not yet created and anattempt to queue work on it causes null-ptr-deref.[1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff[2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf: Fix sample vs do_exit()Baisheng Gao reported an ARM64 crash, which Mark decoded as being asynchronous external abort -- most likely due to trying to accessMMIO in bad ways.The crash further shows perf trying to do a user stack sample while inexit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the addressspace it is trying to access.It turns out that we stop perf after we tear down the userspace mm; areceipie for disaster, since perf likes to access userspace forvarious reasons.Flip this order by moving up where we stop perf in do_exit().Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USERto abort when the current task does not have an mm (exit_mm() makessure to set current->mm = NULL; before commencing with the actualteardown). Such that CPU wide events don't trip on this same problem.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Add basic validation for RAS headerIf RAS header read from EEPROM is corrupted, it could result in tryingto allocate huge memory for reading the records. Add some validation toheader fields.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: nfsd4_spo_must_allow() must check this is a v4 compound requestIf the request being processed is not a v4 compound request, thenexamining the cstate can have undefined results.This patch adds a check that the rpc procedure being executed(rq_procinfo) is the NFSPROC4_COMPOUND procedure.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Intel: hda: Use devm_kstrdup() to avoid memleak.sof_pdata->tplg_filename can have address allocated by kstrdup()and can be overwritten. Memory leak was detected with kmemleak:unreferenced object 0xffff88812391ff60 (size 16): comm "kworker/4:1", pid 161, jiffies 4294802931 hex dump (first 16 bytes): 73 6f 66 2d 68 64 61 2d 67 65 6e 65 72 69 63 00 sof-hda-generic. backtrace (crc 4bf1675c): __kmalloc_node_track_caller_noprof+0x49c/0x6b0 kstrdup+0x46/0xc0 hda_machine_select.cold+0x1de/0x12cf [snd_sof_intel_hda_generic] sof_init_environment+0x16f/0xb50 [snd_sof] sof_probe_continue+0x45/0x7c0 [snd_sof] sof_probe_work+0x1e/0x40 [snd_sof] process_one_work+0x894/0x14b0 worker_thread+0x5e5/0xfb0 kthread+0x39d/0x760 ret_from_fork+0x31/0x70 ret_from_fork_asm+0x1a/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:raid10: cleanup memleak at raid10_make_requestIf raid10_read_request or raid10_write_request registers a newrequest and the REQ_NOWAIT flag is set, the code does notfree the malloc from the mempool.unreferenced object 0xffff8884802c3200 (size 192): comm "fio", pid 9197, jiffies 4298078271 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 88 41 02 00 00 00 00 00 .........A...... 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc c1a049a2): __kmalloc+0x2bb/0x450 mempool_alloc+0x11b/0x320 raid10_make_request+0x19e/0x650 [raid10] md_handle_request+0x3b3/0x9e0 __submit_bio+0x394/0x560 __submit_bio_noacct+0x145/0x530 submit_bio_noacct_nocheck+0x682/0x830 __blkdev_direct_IO_async+0x4dc/0x6b0 blkdev_read_iter+0x1e5/0x3b0 __io_read+0x230/0x1110 io_read+0x13/0x30 io_issue_sqe+0x134/0x1180 io_submit_sqes+0x48c/0xe90 __do_sys_io_uring_enter+0x574/0x8b0 do_syscall_64+0x5c/0xe0 entry_SYSCALL_64_after_hwframe+0x76/0x7eV4: changing backing tree to see if CKI tests will pass.The patch code has not changed between any versions.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid1: Fix stack memory use after return in raid1_reshapeIn the raid1_reshape function, newpool isallocated on the stack and assigned to conf->r1bio_pool.This results in conf->r1bio_pool.wait.head pointingto a stack address.Accessing this address later can lead to a kernel panic.Example access path:raid1_reshape(){ // newpool is on the stack mempool_t newpool, oldpool; // initialize newpool.wait.head to stack address mempool_init(&newpool, ...); conf->r1bio_pool = newpool;}raid1_read_request() or raid1_write_request(){ alloc_r1bio() { mempool_alloc() { // if pool->alloc fails remove_element() { --pool->curr_nr; } } }}mempool_free(){ if (pool->curr_nr < pool->min_nr) { // pool->wait.head is a stack address // wake_up() will try to access this invalid address // which leads to a kernel panic return; wake_up(&pool->wait); }}Fix:reinit conf->r1bio_pool.wait after assigning newpool.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Abort __tc_modify_qdisc if parent class does not existLion's patch [1] revealed an ancient bug in the qdisc API.Whenever a user creates/modifies a qdisc specifying as a parent anotherqdisc, the qdisc API will, during grafting, detect that the user isnot trying to attach to a class and reject. However grafting isperformed after qdisc_create (and thus the qdiscs' init callback) isexecuted. In qdiscs that eventually call qdisc_tree_reduce_backlogduring init or change (such as fq, hhf, choke, etc), an issuearises. For example, executing the following commands:sudo tc qdisc add dev lo root handle a: htb default 2sudo tc qdisc add dev lo parent a: handle beef fqQdiscs such as fq, hhf, choke, etc unconditionally invokeqdisc_tree_reduce_backlog() in their control path init() or change() whichthen causes a failure to find the child class; however, that does not stopthe unconditional invocation of the assumed child qdisc's qlen_notify witha null class. All these qdiscs make the assumption that class is non-null.The solution is ensure that qdisc_leaf() which looks up the parentclass, and is invoked prior to qdisc_create(), should return failure onnot finding the class.In this patch, we leverage qdisc_leaf to return ERR_PTRs whenever theparentid doesn't correspond to a class, so that we can detect itearlier on and abort before qdisc_create is called.[1] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: Fix NULL pointer dereference in vcc_sendmsg()atmarpd_dev_ops does not implement the send method, which may cause crashas bellow.BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: Oops: 0010 [#1] SMP KASAN NOPTICPU: 0 UID: 0 PID: 5324 Comm: syz.0.0 Not tainted 6.15.0-rc6-syzkaller-00346-g5723cc3450bc #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:0x0Code: Unable to access opcode bytes at 0xffffffffffffffd6.RSP: 0018:ffffc9000d3cf778 EFLAGS: 00010246RAX: 1ffffffff1910dd1 RBX: 00000000000000c0 RCX: dffffc0000000000RDX: ffffc9000dc82000 RSI: ffff88803e4c4640 RDI: ffff888052cd0000RBP: ffffc9000d3cf8d0 R08: ffff888052c9143f R09: 1ffff1100a592287R10: dffffc0000000000 R11: 0000000000000000 R12: 1ffff92001a79f00R13: ffff888052cd0000 R14: ffff88803e4c4640 R15: ffffffff8c886e88FS: 00007fbc762566c0(0000) GS:ffff88808d6c2000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffffffffd6 CR3: 0000000041f1b000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: vcc_sendmsg+0xa10/0xc50 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 ____sys_sendmsg+0x52d/0x830 net/socket.c:2566 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620 __sys_sendmmsg+0x227/0x430 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: Fix wraparounds of sk->sk_rmem_alloc.Netlink has this pattern in some places if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) atomic_add(skb->truesize, &sk->sk_rmem_alloc);, which has the same problem fixed by commit 5a465a0da13e ("udp:Fix multiple wraparounds of sk->sk_rmem_alloc.").For example, if we set INT_MAX to SO_RCVBUFFORCE, the conditionis always false as the two operands are of int.Then, a single socket can eat as many skb as possible until OOMhappens, and we can see multiple wraparounds of sk->sk_rmem_alloc.Let's fix it by using atomic_add_return() and comparing the twovariables as unsigned int.Before: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port -1668710080 0 rtnl:nl_wraparound/293 *After: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port 2147483072 0 rtnl:nl_wraparound/290 * ^ `--- INT_MAX - 576
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtimeAssuming the "rx-vlan-filter" feature is enabled on a net device, the8021q module will automatically add or remove VLAN 0 when the net deviceis put administratively up or down, respectively. There are a couple ofproblems with the above scheme.The first problem is a memory leak that can happen if the "rx-vlan-filter"feature is disabled while the device is running: # ip link add bond1 up type bond mode 0 # ethtool -K bond1 rx-vlan-filter off # ip link del dev bond1When the device is put administratively down the "rx-vlan-filter"feature is disabled, so the 8021q module will not remove VLAN 0 and thememory will be leaked [1].Another problem that can happen is that the kernel can automaticallydelete VLAN 0 when the device is put administratively down despite notadding it when the device was put administratively up since during thattime the "rx-vlan-filter" feature was disabled. null-ptr-unref orbug_on[2] will be triggered by unregister_vlan_dev() for refcountimbalance if toggling filtering during runtime:$ ip link add bond0 type bond mode 0$ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q$ ethtool -K bond0 rx-vlan-filter off$ ifconfig bond0 up$ ethtool -K bond0 rx-vlan-filter on$ ifconfig bond0 down$ ip link del vlan0Root cause is as below:step1: add vlan0 for real_dev, such as bond, team.register_vlan_dev vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1step2: disable vlan filter feature and enable real_devstep3: change filter from 0 to 1vlan_device_event vlan_filter_push_vids ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0step4: real_dev downvlan_device_event vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0 vlan_info_rcu_free //free vlan0step5: delete vlan0unregister_vlan_dev BUG_ON(!vlan_info); //vlan_info is nullFix both problems by noting in the VLAN info whether VLAN 0 wasautomatically added upon NETDEV_UP and based on that decide whether itshould be deleted upon NETDEV_DOWN, regardless of the state of the"rx-vlan-filter" feature.[1]unreferenced object 0xffff8880068e3100 (size 256): comm "ip", pid 384, jiffies 4296130254 hex dump (first 32 bytes): 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 81ce31fa): __kmalloc_cache_noprof+0x2b5/0x340 vlan_vid_add+0x434/0x940 vlan_device_event.cold+0x75/0xa8 notifier_call_chain+0xca/0x150 __dev_notify_flags+0xe3/0x250 rtnl_configure_link+0x193/0x260 rtnl_newlink_create+0x383/0x8e0 __rtnl_newlink+0x22c/0xa40 rtnl_newlink+0x627/0xb00 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x11f/0x350 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180[2]kernel BUG at net/8021q/vlan.c:99!Oops: invalid opcode: 0000 [#1] SMP KASAN PTICPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1))RSP: 0018:ffff88810badf310 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9aRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017eFS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0Call Trace:
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: net: sierra: check for no status endpointThe driver checks for having three endpoints andhaving bulk in and out endpoints, but not thatthe third endpoint is interrupt input.Rectify the omission.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: aspeed: lpc-snoop: Don't disable channels that aren't enabledMitigate e.g. the following: # echo 1e789080.lpc-snoop > /sys/bus/platform/drivers/aspeed-lpc-snoop/unbind ... [ 120.363594] Unable to handle kernel NULL pointer dereference at virtual address 00000004 when write [ 120.373866] [00000004] *pgd=00000000 [ 120.377910] Internal error: Oops: 805 [#1] SMP ARM [ 120.383306] CPU: 1 UID: 0 PID: 315 Comm: sh Not tainted 6.15.0-rc1-00009-g926217bc7d7d-dirty #20 NONE ... [ 120.679543] Call trace: [ 120.679559] misc_deregister from aspeed_lpc_snoop_remove+0x84/0xac [ 120.692462] aspeed_lpc_snoop_remove from platform_remove+0x28/0x38 [ 120.700996] platform_remove from device_release_driver_internal+0x188/0x200 ...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix assertion when building free space treeWhen building the free space tree with the block group tree featureenabled, we can hit an assertion failure like this: BTRFS info (device loop0 state M): rebuilding free space tree assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1102! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 1 UID: 0 PID: 6592 Comm: syz-executor322 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 lr : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 sp : ffff8000a4ce7600 x29: ffff8000a4ce76e0 x28: ffff0000c9bc6000 x27: ffff0000ddfff3d8 x26: ffff0000ddfff378 x25: dfff800000000000 x24: 0000000000000001 x23: ffff8000a4ce7660 x22: ffff70001499cecc x21: ffff0000e1d8c160 x20: ffff0000e1cb7800 x19: ffff0000e1d8c0b0 x18: 00000000ffffffff x17: ffff800092f39000 x16: ffff80008ad27e48 x15: ffff700011e740c0 x14: 1ffff00011e740c0 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011e740c0 x10: 0000000000ff0100 x9 : 94ef24f55d2dbc00 x8 : 94ef24f55d2dbc00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000a4ce6f98 x4 : ffff80008f415ba0 x3 : ffff800080548ef0 x2 : 0000000000000000 x1 : 0000000100000000 x0 : 000000000000003e Call trace: populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 (P) btrfs_rebuild_free_space_tree+0x14c/0x54c fs/btrfs/free-space-tree.c:1337 btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074 btrfs_remount_rw fs/btrfs/super.c:1319 [inline] btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543 reconfigure_super+0x1d4/0x6f0 fs/super.c:1083 do_remount fs/namespace.c:3365 [inline] path_mount+0xb34/0xde0 fs/namespace.c:4200 do_mount fs/namespace.c:4221 [inline] __do_sys_mount fs/namespace.c:4432 [inline] __se_sys_mount fs/namespace.c:4409 [inline] __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Code: f0047182 91178042 528089c3 9771d47b (d4210000) ---[ end trace 0000000000000000 ]---This happens because we are processing an empty block group, which hasno extents allocated from it, there are no items for this block group,including the block group item since block group items are stored in adedicated tree when using the block group tree feature. It also meansthis is the block group with the highest start offset, so there are nohigher keys in the extent root, hence btrfs_search_slot_for_read()returns 1 (no higher key found).Fix this by asserting 'ret' is 0 only if the block group tree featureis not enabled, in which case we should find a block group item forthe block group since it's stored in the extent root and block groupitem keys are greater than extent item keys (the value forBTRFS_BLOCK_GROUP_ITEM_KEY is 192 and for BTRFS_EXTENT_ITEM_KEY andBTRFS_METADATA_ITEM_KEY the values are 168 and 169 respectively).In case 'ret' is 1, we just need to add a record to the free spacetree which spans the whole block group, and we can achieve this bymaking 'ret == 0' as the while loop's condition.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: reject VHT opmode for unsupported channel widthsVHT operating mode notifications are not defined for channel widthsbelow 20 MHz. In particular, 5 MHz and 10 MHz are not valid under theVHT specification and must be rejected.Without this check, malformed notifications using these widths mayreach ieee80211_chan_width_to_rx_bw(), leading to a WARN_ON due toinvalid input. This issue was reported by syzbot.Reject these unsupported widths early in sta_link_apply_parameters()when opmode_notif is used. The accepted set includes 20, 40, 80, 160,and 80+80 MHz, which are valid for VHT. While 320 MHz is not definedfor VHT, it is allowed to avoid rejecting HE or EHT clients that maystill send a VHT opmode notification.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: qcom: msm: mark certain pins as invalid for interruptsOn some platforms, the UFS-reset pin has no interrupt logic in TLMM butis nevertheless registered as a GPIO in the kernel. This enables theuser-space to trigger a BUG() in the pinctrl-msm driver by running, forexample: `gpiomon -c 0 113` on RB2.The exact culprit is requesting pins whose intr_detection_width settingis not 1 or 2 for interrupts. This hits a BUG() inmsm_gpio_irq_set_type(). Potentially crashing the kernel due to aninvalid request from user-space is not optimal, so let's go through thepins and mark those that would fail the check as invalid for the irq chipas we should not even register them as available irqs.This function can be extended if we determine that there are morecorner-cases like this.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix recv-recv race of completed callIf a call receives an event (such as incoming data), the call gets placedon the socket's queue and a thread in recvmsg can be awakened to go andprocess it. Once the thread has picked up the call off of the queue,further events will cause it to be requeued, and once the socket lock isdropped (recvmsg uses call->user_mutex to allow the socket to be used inparallel), a second thread can come in and its recvmsg can pop the call offthe socket queue again.In such a case, the first thread will be receiving stuff from the call andthe second thread will be blocked on call->user_mutex. The first threadcan, at this point, process both the event that it picked call for and theevent that the second thread picked the call for and may see the callterminate - in which case the call will be "released", decoupling the callfrom the user call ID assigned to it (RXRPC_USER_CALL_ID in the controlmessage).The first thread will return okay, but then the second thread will wake upholding the user_mutex and, if it sees that the call has been released bythe first thread, it will BUG thusly: kernel BUG at net/rxrpc/recvmsg.c:474!Fix this by just dequeuing the call and ignoring it if it is seen to bealready released. We can't tell userspace about it anyway as the user callID has become stale.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:phy: tegra: xusb: Fix unbalanced regulator disable in UTMI PHY modeWhen transitioning from USB_ROLE_DEVICE to USB_ROLE_NONE, the codeassumed that the regulator should be disabled. However, if the regulatoris marked as always-on, regulator_is_enabled() continues to return true,leading to an incorrect attempt to disable a regulator which is notenabled.This can result in warnings such as:[ 250.155624] WARNING: CPU: 1 PID: 7326 at drivers/regulator/core.c:3004_regulator_disable+0xe4/0x1a0[ 250.155652] unbalanced disables for VIN_SYS_5V0To fix this, we move the regulator control logic intotegra186_xusb_padctl_id_override() function since it's directly relatedto the ID override state. The regulator is now only disabled when the roletransitions from USB_ROLE_HOST to USB_ROLE_NONE, by checking the VBUS_IDregister. This ensures that regulator enable/disable operations areproperly balanced and only occur when actually transitioning to/from hostmode.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP CamerasThe Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 & 04F2:B82C)report a HID sensor interface that is not actually implemented.Attempting to access this non-functional sensor via iio_info causessystem hangs as runtime PM tries to wake up an unresponsive sensor.Add these 2 devices to the HID ignore list since the sensor interface isnon-functional by design and should not be exposed to userspace.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/tegra: nvdec: Fix dma_alloc_coherent error checkCheck for NULL return value with dma_alloc_coherent, in line withRobin's fix for vic.c in 'drm/tegra: vic: Fix DMA API misuse'.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (corsair-cpro) Validate the size of the received input bufferAdd buffer_recv_size to store the size of the received bytes.Validate buffer_recv_size in send_usb_cmd().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: Delay put pmc->idev in mld_del_delrec()pmc->idev is still used in ip6_mc_clear_src(), so as mld_clear_delrec()does, the reference should be put after ip6_mc_clear_src() return.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: ccp - Fix crash when rebind ccp device for ccp.koWhen CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebindingthe ccp device causes the following crash:$ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind$ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind[ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098[ 204.978026] #PF: supervisor write access in kernel mode[ 204.979126] #PF: error_code(0x0002) - not-present page[ 204.980226] PGD 0 P4D 0[ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI...[ 204.997852] Call Trace:[ 204.999074] [ 205.000297] start_creating+0x9f/0x1c0[ 205.001533] debugfs_create_dir+0x1f/0x170[ 205.002769] ? srso_return_thunk+0x5/0x5f[ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp][ 205.005241] ccp5_init+0x8b2/0x960 [ccp][ 205.006469] ccp_dev_init+0xd4/0x150 [ccp][ 205.007709] sp_init+0x5f/0x80 [ccp][ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp][ 205.010165] ? srso_return_thunk+0x5/0x5f[ 205.011376] local_pci_probe+0x4f/0xb0[ 205.012584] pci_device_probe+0xdb/0x230[ 205.013810] really_probe+0xed/0x380[ 205.015024] __driver_probe_device+0x7e/0x160[ 205.016240] device_driver_attach+0x2f/0x60[ 205.017457] bind_store+0x7c/0xb0[ 205.018663] drv_attr_store+0x28/0x40[ 205.019868] sysfs_kf_write+0x5f/0x70[ 205.021065] kernfs_fop_write_iter+0x145/0x1d0[ 205.022267] vfs_write+0x308/0x440[ 205.023453] ksys_write+0x6d/0xe0[ 205.024616] __x64_sys_write+0x1e/0x30[ 205.025778] x64_sys_call+0x16ba/0x2150[ 205.026942] do_syscall_64+0x56/0x1e0[ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 205.029276] RIP: 0033:0x7fbc36f10104[ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5This patch sets ccp_debugfs_dir to NULL after destroying it inccp5_debugfs_destroy, allowing the directory dentry to berecreated when rebinding the ccp device.Tested on AMD Ryzen 7 1700X.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: xilinx: vcu: unregister pll_post only if registered correctlyIf registration of pll_post is failed, it will be set to NULL or ERR,unregistering same will fail with following call trace:Unable to handle kernel NULL pointer dereference at virtual address 008pc : clk_hw_unregister+0xc/0x20lr : clk_hw_unregister_fixed_factor+0x18/0x30sp : ffff800011923850...Call trace: clk_hw_unregister+0xc/0x20 clk_hw_unregister_fixed_factor+0x18/0x30 xvcu_unregister_clock_provider+0xcc/0xf4 [xlnx_vcu] xvcu_probe+0x2bc/0x53c [xlnx_vcu]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Remove skb secpath if xfrm state is not foundHardware returns a unique identifier for a decrypted packet's xfrmstate, this state is looked up in an xarray. However, the state mighthave been freed by the time of this lookup.Currently, if the state is not found, only a counter is incremented.The secpath (sp) extension on the skb is not removed, resulting insp->len becoming 0.Subsequently, functions like __xfrm_policy_check() attempt to accessfields such as xfrm_input_state(skb)->xso.type (which dereferencessp->xvec[sp->len - 1]) without first validating sp->len. This leads toa crash when dereferencing an invalid state pointer.This patch prevents the crash by explicitly removing the secpathextension from the skb if the xfrm state is not found after hardwaredecryption. This ensures downstream functions do not operate on azero-length secpath. BUG: unable to handle page fault for address: ffffffff000002c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__xfrm_policy_check+0x61a/0xa30 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? try_to_wake_up+0x108/0x4c0 ? udp4_lib_lookup2+0xbe/0x150 ? udp_lib_lport_inuse+0x100/0x100 ? __udp4_lib_lookup+0x2b0/0x410 __xfrm_policy_check2.constprop.0+0x11e/0x130 udp_queue_rcv_one_skb+0x1d/0x530 udp_unicast_rcv_skb+0x76/0x90 __udp4_lib_rcv+0xa64/0xe90 ip_protocol_deliver_rcu+0x20/0x130 ip_local_deliver_finish+0x75/0xa0 ip_local_deliver+0xc1/0xd0 ? ip_protocol_deliver_rcu+0x130/0x130 ip_sublist_rcv+0x1f9/0x240 ? ip_rcv_finish_core+0x430/0x430 ip_list_rcv+0xfc/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x200/0x360 ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core] gro_receive_skb+0xfd/0x210 mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core] mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core] ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core] mlx5e_napi_poll+0x114/0xab0 [mlx5_core] __napi_poll+0x25/0x170 net_rx_action+0x32d/0x3a0 ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core] ? notifier_call_chain+0x33/0xa0 handle_softirqs+0xda/0x250 irq_exit_rcu+0x6d/0xc0 common_interrupt+0x81/0xa0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: clear initialized flag for deinit-ed srng listsIn a number of cases we see kernel panics on resume dueto ath11k kernel page fault, which happens under thefollowing circumstances:1) First ath11k_hal_dump_srng_stats() call Last interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0 22511ms before ath11k_pci 0000:01:00.0: group_id 1 14440788ms before [..] ath11k_pci 0000:01:00.0: failed to receive control response completion, polling.. ath11k_pci 0000:01:00.0: Service connect timeout ath11k_pci 0000:01:00.0: failed to connect to HTT: -110 ath11k_pci 0000:01:00.0: failed to start core: -110 ath11k_pci 0000:01:00.0: firmware crashed: MHI_CB_EE_RDDM ath11k_pci 0000:01:00.0: already resetting count 2 ath11k_pci 0000:01:00.0: failed to wait wlan mode request (mode 4): -110 ath11k_pci 0000:01:00.0: qmi failed to send wlan mode off: -110 ath11k_pci 0000:01:00.0: failed to reconfigure driver on crash recovery [..]2) At this point reconfiguration fails (we have 2 resets) and ath11k_core_reconfigure_on_crash() calls ath11k_hal_srng_deinit() which destroys srng lists. However, it does not reset per-list ->initialized flag.3) Second ath11k_hal_dump_srng_stats() call sees stale ->initialized flag and attempts to dump srng stats: Last interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0 66785ms before ath11k_pci 0000:01:00.0: group_id 1 14485062ms before ath11k_pci 0000:01:00.0: group_id 2 14485062ms before ath11k_pci 0000:01:00.0: group_id 3 14485062ms before ath11k_pci 0000:01:00.0: group_id 4 14780845ms before ath11k_pci 0000:01:00.0: group_id 5 14780845ms before ath11k_pci 0000:01:00.0: group_id 6 14485062ms before ath11k_pci 0000:01:00.0: group_id 7 66814ms before ath11k_pci 0000:01:00.0: group_id 8 68997ms before ath11k_pci 0000:01:00.0: group_id 9 67588ms before ath11k_pci 0000:01:00.0: group_id 10 69511ms before BUG: unable to handle page fault for address: ffffa007404eb010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 10022d067 PMD 100b01067 PTE 0 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k] Call Trace: ? __die_body+0xae/0xb0 ? page_fault_oops+0x381/0x3e0 ? exc_page_fault+0x69/0xa0 ? asm_exc_page_fault+0x22/0x30 ? ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)] ath11k_qmi_driver_event_work+0xbd/0x1050 [ath11k (HASH:6cea 4)] worker_thread+0x389/0x930 kthread+0x149/0x170Clear per-list ->initialized flag in ath11k_hal_srng_deinit().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iwlwifi: Add missing check for alloc_ordered_workqueueAdd check for the return value of alloc_ordered_workqueue since it mayreturn NULL pointer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: Check governor before using governor->nameCommit 96ffcdf239de ("PM / devfreq: Remove redundant governor_name fromstruct devfreq") removes governor_name and uses governor->name to replaceit. But devfreq->governor may be NULL and directly usingdevfreq->governor->name may cause null pointer exception. Move the check ofgovernor to before using governor->name.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc()In the error paths after fb_info structure is successfully allocated,the memory allocated in fb_deferred_io_init() for info->pagerefs is notfreed. Fix that by adding the cleanup function on the error path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eventpoll: Fix semi-unbounded recursionEnsure that epoll instances can never form a graph deeper thanEP_MAX_NESTS+1 links.Currently, ep_loop_check_proc() ensures that the graph is loop-free anddoes some recursion depth checks, but those recursion depth checks don'tlimit the depth of the resulting tree for two reasons: - They don't look upwards in the tree. - If there are multiple downwards paths of different lengths, only one of the paths is actually considered for the depth check since commit 28d82dc1c4ed ("epoll: limit paths").Essentially, the current recursion depth check in ep_loop_check_proc() justserves to prevent it from recursing too deeply while checking for loops.A more thorough check is done in reverse_path_check() after the new graphedge has already been created; this checks, among other things, that nopaths going upwards from any non-epoll file with a length of more than 5edges exist. However, this check does not apply to non-epoll files.As a result, it is possible to recurse to a depth of at least roughly 500,tested on v6.15. (I am unsure if deeper recursion is possible; and this mayhave changed with commit 8c44dac8add7 ("eventpoll: Fix priority inversionproblem").)To fix it:1. In ep_loop_check_proc(), note the subtree depth of each visited node,and use subtree depths for the total depth calculation even when a subtreehas already been visited.2. Add ep_get_upwards_depth_proc() for similarly determining the maximumdepth of an upwards walk.3. In ep_loop_check(), use these values to limit the total path lengthbetween epoll nodes to EP_MAX_NESTS edges.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: drop UFO packets in udp_rcv_segment()When sending a packet with virtio_net_hdr to tun device, if the gso_typein virtio_net_hdr is SKB_GSO_UDP and the gso_size is less than udphdrsize, below crash may happen. ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:4572! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 62 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:skb_pull_rcsum+0x8e/0xa0 Code: 00 00 5b c3 cc cc cc cc 8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8 00 00 00 5b c3 cc cc cc cc <0f> 0b 0f 0b 66 66 2e 0f 1f 84 00 000 RSP: 0018:ffffc900001fba38 EFLAGS: 00000297 RAX: 0000000000000004 RBX: ffff8880040c1000 RCX: ffffc900001fb948 RDX: ffff888003e6d700 RSI: 0000000000000008 RDI: ffff88800411a062 RBP: ffff8880040c1000 R08: 0000000000000000 R09: 0000000000000001 R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000 R13: ffff888004060900 R14: ffff888004050000 R15: ffff888004060900 FS: 000000002406d3c0(0000) GS:ffff888084a19000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000040 CR3: 0000000004007000 CR4: 00000000000006f0 Call Trace: udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445 udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475 udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626 __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690 ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233 ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579 ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636 ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670 __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067 netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210 napi_complete_done+0x78/0x180 net/core/dev.c:6580 tun_get_user+0xa63/0x1120 drivers/net/tun.c:1909 tun_chr_write_iter+0x65/0xb0 drivers/net/tun.c:1984 vfs_write+0x300/0x420 fs/read_write.c:593 ksys_write+0x60/0xd0 fs/read_write.c:686 do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63 To trigger gso segment in udp_queue_rcv_skb(), we should also set optionUDP_ENCAP_ESPINUDP to enable udp_sk(sk)->encap_rcv. When the encap_rcvhook return 1 in udp_queue_rcv_one_skb(), udp_csum_pull_header() will tryto pull udphdr, but the skb size has been segmented to gso size, whichleads to this crash.Previous commit cf329aa42b66 ("udp: cope with UDP GRO packet misdirection")introduces segmentation in UDP receive path only for GRO, which was neverintended to be used for UFO, so drop UFO packets in udp_rcv_segment().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: pnv_php: Clean up allocated IRQs on unplugWhen the root of a nested PCIe bridge configuration is unplugged, thepnv_php driver leaked the allocated IRQ resources for the child bridges'hotplug event notifications, resulting in a panic.Fix this by walking all child buses and deallocating all its IRQ resourcesbefore calling pci_hp_remove_devices().Also modify the lifetime of the workqueue at struct pnv_php_slot::wq sothat it is only destroyed in pnv_php_free_slot(), instead ofpnv_php_disable_irq(). This is required since pnv_php_disable_irq() willnow be called by workers triggered by hot unplug interrupts, so theworkqueue needs to stay allocated.The abridged kernel panic that occurs without this patch is as follows: WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2 Call Trace: msi_device_data_release+0x34/0x9c (unreliable) release_nodes+0x64/0x13c devres_release_all+0xc0/0x140 device_del+0x2d4/0x46c pci_destroy_dev+0x5c/0x194 pci_hp_remove_devices+0x90/0x128 pci_hp_remove_devices+0x44/0x128 pnv_php_disable_slot+0x54/0xd4 power_write_file+0xf8/0x18c pci_slot_attr_store+0x40/0x5c sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x290 vfs_write+0x3bc/0x50c ksys_write+0x84/0x140 system_call_exception+0x124/0x230 system_call_vectored_common+0x15c/0x2ec[bhelgaas: tidy comments]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:power: supply: cpcap-charger: Fix null check for power_supply_get_by_nameIn the cpcap_usb_detect() function, the power_supply_get_by_name()function may return `NULL` instead of an error pointer.To prevent potential null pointer dereferences, Added a null check.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()Callers of wdev_chandef() must hold the wiphy mutex.But the worker cfg80211_propagate_cac_done_wk() never takes the lock.Which triggers the warning below with the mesh_peer_connected_dfstest from hostapd and not (yet) released mac80211 code changes:WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165Modules linked in:CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cfWorkqueue: cfg80211 cfg80211_propagate_cac_done_wkStack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64irq event stamp: 614611hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xafhardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xafsoftirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Check device memory pointer before usageAdd a NULL check before accessing device memory to prevent a crash ifdev->dm allocation in mlx5_init_once() fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: canaan: k230: add NULL check in DT parseAdd a NULL check for the return value of of_get_property() whenretrieving the "pinmux" property in the group parser. This avoidsa potential NULL pointer dereference if the property is missingfrom the device tree node.Also fix a typo ("sintenel") in the device ID match table comment,correcting it to "sentinel".
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:[ceph] parse_longname(): strrchr() expects NUL-terminated string... and parse_longname() is not guaranteed that. That's the reasonwhy it uses kmemdup_nul() to build the argument for kstrtou64();the problem is, kstrtou64() is not the only thing that need it.Just get a NUL-terminated copy of the entire thing and be donewith that...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: reject invalid file types when reading inodesTo prevent inodes with invalid file types from tripping through the vfsand causing malfunctions or assertion failures, add a missing sanity checkwhen reading an inode from a block device. If the file type is not valid,treat it as a filesystem error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_modeAndrei Lalaev reported a NULL pointer deref when a CAN device isrestarted from Bus Off and the driver does not implement the structcan_priv::do_set_mode callback.There are 2 code path that call struct can_priv::do_set_mode:- directly by a manual restart from the user space, via can_changelink()- delayed automatic restart after bus off (deactivated by default)To prevent the NULL pointer deference, refuse a manual restart orconfigure the automatic restart delay in can_changelink() and reportthe error via extack to user space.As an additional safety measure let can_restart() return an error ifcan_priv::do_set_mode is not set instead of dereferencing itunchecked.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: fix NULL dereference on unbind due to stale coupling dataFailing to reset coupling_desc.n_coupled after freeing coupled_rdevs canlead to NULL pointer dereference when regulators are accessed post-unbind.This can happen during runtime PM or other regulator operations that relyon coupling metadata.For example, on ridesx4, unbinding the 'reg-dummy' platform device triggersa panic in regulator_lock_recursive() due to stale coupling state.Ensure n_coupled is set to 0 to prevent access to invalid pointers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()`cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to changeto different stacks along with the Shadow Call Stack if it is enabled.Those two stack changes cannot be done atomically and both functionscan be interrupted by SErrors or Debug Exceptions which, though unlikely,is very much broken : if interrupted, we can end up with mismatched stacksand Shadow Call Stack leading to clobbered stacks.In `cpu_switch_to()`, it can happen when SP_EL0 points to the new task,but x18 stills points to the old task's SCS. When the interrupt handlertries to save the task's SCS pointer, it will save the old taskSCS pointer (x18) into the new task struct (pointed to by SP_EL0),clobbering it.In `call_on_irq_stack()`, it can happen when switching from the task stackto the IRQ stack and when switching back. In both cases, we can beinterrupted when the SCS pointer points to the IRQ SCS, but SP points tothe task stack. The nested interrupt handler pushes its return addresseson the IRQ SCS. It then detects that SP points to the task stack,calls `call_on_irq_stack()` and clobbers the task SCS pointer withthe IRQ SCS pointer, which it will also use !This leads to tasks returning to addresses on the wrong SCS,or even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACKor FPAC if enabled.This is possible on a default config, but unlikely.However, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked andinstead the GIC is responsible for filtering what interrupts the CPUshould receive based on priority.Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPUeven in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very*frequently depending on the system configuration and workload, leadingto unpredictable kernel panics.Completely mask DAIF in `cpu_switch_to()` and restore it when returning.Do the same in `call_on_irq_stack()`, but restore and mask aroundthe branch.Mask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistencyof behaviour between all configurations.Introduce and use an assembly macro for saving and masking DAIF,as the existing one saves but only masks IF.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: qup: jump out of the loop in case of timeoutOriginal logic only sets the return value but doesn't jump out of theloop if the bus is kept active by a client. This is not expected. Amalicious or buggy i2c client can hang the kernel in this case andshould be avoided. This is observed during a long time test with aPCA953x GPIO extender.Fix it by changing the logic to not only sets the return value, but alsojumps out of the loop and return to the caller with -ETIMEDOUT.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: state: initialize state_ptrs earlier in xfrm_state_findIn case of preemption, xfrm_state_look_at will find a differentpcpu_id and look up states for that other CPU. If we matched a statefor CPU2 in the state_cache while the lookup started on CPU1, we willjump to "found", but the "best" state that we got will be ignored andwe will enter the "acquire" block. This block uses state_ptrs, whichisn't initialized at this point.Let's initialize state_ptrs just after taking rcu_read_lock. This willalso prevent a possible misuse in the future, if someone adjusts thisfunction.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format()The buffer length check before calling uvc_parse_format() only ensuredthat the buffer has at least 3 bytes (buflen > 2), buf the functionaccesses buffer[3], requiring at least 4 bytes.This can lead to an out-of-bounds read if the buffer has exactly 3 bytes.Fix it by checking that the buffer has at least 4 bytes inuvc_parse_format().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/ptdump: take the memory hotplug lock inside ptdump_walk_pgd()Memory hot remove unmaps and tears down various kernel page table regionsas required. The ptdump code can race with concurrent modifications ofthe kernel page tables. When leaf entries are modified concurrently, thedump code may log stale or inconsistent information for a VA range, butthis is otherwise not harmful.But when intermediate levels of kernel page table are freed, the dump codewill continue to use memory that has been freed and potentiallyreallocated for another purpose. In such cases, the ptdump code maydereference bogus addresses, leading to a number of potential problems.To avoid the above mentioned race condition, platforms such as arm64,riscv and s390 take memory hotplug lock, while dumping kernel page tablevia the sysfs interface /sys/kernel/debug/kernel_page_tables.Similar race condition exists while checking for pages that might havebeen marked W+X via /sys/kernel/debug/kernel_page_tables/check_wx_pageswhich in turn calls ptdump_check_wx(). Instead of solving this racecondition again, let's just move the memory hotplug lock inside genericptdump_check_wx() which will benefit both the scenarios.Drop get_online_mems() and put_online_mems() combination from all existingplatform ptdump code paths.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:userfaultfd: fix a crash in UFFDIO_MOVE when PMD is a migration entryWhen UFFDIO_MOVE encounters a migration PMD entry, it proceeds withobtaining a folio and accessing it even though the entry is swp_entry_t. Add the missing check and let split_huge_pmd() handle migration entries. While at it also remove unnecessary folio check.[surenb@google.com: remove extra folio check, per David]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: fix race between polling and detachingsyzbot reports a use-after-free in comedi in the below link, which isdue to comedi gladly removing the allocated async area even though pollrequests are still active on the wait_queue_head inside of it. This cancause a use-after-free when the poll entries are later triggered orremoved, as the memory for the wait_queue_head has been freed. We needto check there are no tasks queued on any of the subdevices' wait queuesbefore allowing the device to be detached by the `COMEDI_DEVCONFIG`ioctl.Tasks will read-lock `dev->attach_lock` before adding themselves to thesubdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctlhandler by write-locking `dev->attach_lock` before checking that all ofthe subdevices are safe to be deleted. This includes testing for anysleepers on the subdevices' wait queues. It remains locked until thedevice has been detached. This requires the `comedi_device_detach()`function to be refactored slightly, moving the bulk of it into newfunction `comedi_device_detach_locked()`.Note that the refactor of `comedi_device_detach()` results in`comedi_device_cancel_all()` now being called while `dev->attach_lock`is write-locked, which wasn't the case previously, but that does notmatter.Thanks to Jens Axboe for diagnosing the problem and co-developing thispatch.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommufd: Prevent ALIGN() overflowWhen allocating IOVA the candidate range gets aligned to the targetalignment. If the range is close to ULONG_MAX then the ALIGN() canwrap resulting in a corrupted iova.Open code the ALIGN() using get_add_overflow() to prevent this.This simplifies the checks as we don't need to check for length earliereither.Consolidate the two copies of this code under a single helper.This bug would allow userspace to create a mapping that overlaps with someother mapping or a reserved range.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pNFS: Fix uninited ptr deref in block/scsi layoutThe error occurs on the third attempt to encode extents. When functionext_tree_prepare_commit() reallocates a larger buffer to retry encodingextents, the "layoutupdate_pages" page array is initialized only after theretry loop. But ext_tree_free_commitdata() is called on every iterationand tries to put pages in the array, thus dereferencing uninitializedpointers.An additional problem is that there is no limit on the maximum possiblebuffer_size. When there are too many extents, the client may create alayoutcommit that is larger than the maximum possible RPC size acceptedby the server.During testing, we observed two typical scenarios. First, one memory pagefor extents is enough when we work with small files, append data to theend of the file, or preallocate extents before writing. But when we filla new large file without preallocating, the number of extents can be huge,and counting the number of written extents in ext_tree_encode_commit()does not help much. Since this number increases even more betweenunlocking and locking of ext_tree, the reallocated buffer may not belarge enough again and again.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-frontends: w7090p: fix null-ptr-deref in w7090p_tuner_write_serpar and w7090p_tuner_read_serparIn w7090p_tuner_write_serpar, msg is controlled by user. When msg[0].buf is null and msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing msg[0].buf[2] without sanity check, null pointer deref would happen. We addcheck on msg[0].len to prevent crash.Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix null pointer accessWriting a string without delimiters (' ', '\n', '\0') to the undergpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profilewill result in a null pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()When the volume header contains erroneous values that do not reflectthe actual state of the filesystem, hfsplus_fill_super() assumes thatthe attributes file is not yet created, which later results in hittingBUG_ON() when hfsplus_create_attributes_file() is called. Replace thisBUG_ON() with -EIO error with a message to suggest running fsck tool.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: kcm: Fix race condition in kcm_unattach()syzbot found a race condition when kcm_unattach(psock)and kcm_release(kcm) are executed at the same time.kcm_unattach() is missing a check of the flagkcm->tx_stopped before calling queue_work().If the kcm has a reserved psock, kcm_unattach() might get executedbetween cancel_work_sync() and unreserve_psock() in kcm_release(),requeuing kcm->tx_work right before kcm gets freed in kcm_done().Remove kcm->tx_stopped and replace it by the lesserror-prone disable_work_sync().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: linearize cloned gso packets in sctp_rcvA cloned head skb still shares these frag skbs in fraglist with theoriginal head skb. It's not safe to access these frag skbs.syzbot reported two use-of-uninitialized-memory bugs caused by this: BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122 __release_sock+0x1da/0x330 net/core/sock.c:3106 release_sock+0x6b/0x250 net/core/sock.c:3660 sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360 sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885 sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031 inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:718 [inline]and BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367 sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886 sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032 inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline]This patch fixes it by linearizing cloned gso packets in sctp_rcv().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hibmcge: fix the division by zero issueWhen the network port is down, the queue is released, and ring->len is 0.In debugfs, hbg_get_queue_used_num() will be called,which may lead to a division by zero issue.This patch adds a check, if ring->len is 0,hbg_get_queue_used_num() directly returns 0.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: fix refcount leak on table dumpThere is a reference count leak in ctnetlink_dump_table(): if (res < 0) { nf_conntrack_get(&ct->ct_general); // HERE cb->args[1] = (unsigned long)ct; ...While its very unlikely, its possible that ct == last.If this happens, then the refcount of ct was already incremented.This 2nd increment is never undone.This prevents the conntrack object from being released, which in turnkeeps prevents cnet->count from dropping back to 0.This will then block the netns dismantle (or conntrack rmmod) asnf_conntrack_cleanup_net_list() will wait forever.This can be reproduced by running conntrack_resize.sh selftest in a loop.It takes ~20 minutes for me on a preemptible kernel on average beforeI see a runaway kworker spinning in nf_conntrack_cleanup_net_list.One fix would to change this to: if (res < 0) { if (ct != last) nf_conntrack_get(&ct->ct_general);But this reference counting isn't needed in the first place.We can just store a cookie value instead.A followup patch will do the same for ctnetlink_exp_dump_table,it looks to me as if this has the same problem and likectnetlink_dump_table, we only need a 'skip hint', not the actualobject so we can apply the same cookie strategy there as well.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:habanalabs: fix UAF in export_dmabuf()As soon as we'd inserted a file reference into descriptor table, anotherthread could close it. That's fine for the case when all we are doing isreturning that descriptor to userland (it's a race, but it's a userlandrace and there's nothing the kernel can do about it). However, if wefollow fd_install() with any kind of access to objects that would bedestroyed on close (be it the struct file itself or anything destroyedby its ->release()), we have a UAF.dma_buf_fd() is a combination of reserving a descriptor and fd_install().habanalabs export_dmabuf() calls it and then proceeds to access theobjects destroyed on close. In particular, it grabs an extra reference toanother struct file that will be dropped as part of ->release() for ours;that "will be" is actually "might have already been".Fix that by reserving descriptor before anything else and do fd_install()only when everything had been set up. As a side benefit, we no longerhave the failure exit with file already created, but reference tounderlying file (as well as ->dmabuf_export_cnt, etc.) not grabbed yet;unlike dma_buf_fd(), fd_install() can't fail.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:LoongArch: BPF: Fix jump offset calculation in tailcallThe extra pass of bpf_int_jit_compile() skips JIT context initializationwhich essentially skips offset calculation leaving out_offset = -1, sothe jmp_offset in emit_bpf_tail_call is calculated by"#define jmp_offset (out_offset - (cur_offset))"is a negative number, which is wrong. The final generated assembly areas follow.54: bgeu $a2, $t1, -8 # 0x0000004c58: addi.d $a6, $s5, -15c: bltz $a6, -16 # 0x0000004c60: alsl.d $t2, $a2, $a1, 0x364: ld.d $t2, $t2, 26468: beq $t2, $zero, -28 # 0x0000004cBefore apply this patch, the follow test case will reveal soft lock issues.cd tools/testing/selftests/bpf/./test_progs --allow=tailcalls/tailcall_bpf2bpf_1dmesg:watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [test_progs:25056]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()Lei Lu recently reported that nfsd4_setclientid_confirm() did not checkthe return value from get_client_locked(). a SETCLIENTID_CONFIRM couldrace with a confirmed client expiring and fail to get a reference. Thatcould later lead to a UAF.Fix this by getting a reference early in the case where there is anextant confirmed client. If that fails then treat it as if there were noconfirmed client found at all.In the case where the unconfirmed client is expiring, just fail andreturn the result from get_client_locked().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: asix_devices: add phy_mask for ax88772 mdio busWithout setting phy_mask for ax88772 mdio bus, current driver may createat most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f.DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phydevice will bind to net phy driver. This is creating issue during systemsuspend/resume since phy_polling_mode() in phy_state_machine() willdirectly deference member of phydev->drv for non-main phy devices. ThenNULL pointer dereference issue will occur. Due to only external phy orinternal phy is necessary, add phy_mask for ax88772 mdio bus to workarnoudthe issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ftgmac100: fix potential NULL pointer access in ftgmac100_phy_disconnectAfter the call to phy_disconnect() netdev->phydev is reset to NULL.So fixed_phy_unregister() would be called with a NULL pointer as argument.Therefore cache the phy_device before this call.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb3: fix for slab out of bounds on mount to ksmbdWith KASAN enabled, it is possible to get a slab out of boundsduring mount to ksmbd due to missing check in parse_server_interfaces()(see below): BUG: KASAN: slab-out-of-bounds in parse_server_interfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827 CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: dump_stack_lvl+0x9f/0xf0 print_report+0xd1/0x670 __virt_addr_valid+0x22c/0x430 ? parse_server_interfaces+0x14ee/0x1880 [cifs] ? kasan_complete_mode_report_info+0x2a/0x1f0 ? parse_server_interfaces+0x14ee/0x1880 [cifs] kasan_report+0xd6/0x110 parse_server_interfaces+0x14ee/0x1880 [cifs] __asan_report_load_n_noabort+0x13/0x20 parse_server_interfaces+0x14ee/0x1880 [cifs] ? __pfx_parse_server_interfaces+0x10/0x10 [cifs] ? trace_hardirqs_on+0x51/0x60 SMB3_request_interfaces+0x1ad/0x3f0 [cifs] ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs] ? SMB2_tcon+0x23c/0x15d0 [cifs] smb3_qfs_tcon+0x173/0x2b0 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] ? cifs_get_tcon+0x105d/0x2120 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_get_tcon+0x105d/0x2120 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] cifs_mount_get_tcon+0x369/0xb90 [cifs] ? dfs_cache_find+0xe7/0x150 [cifs] dfs_mount_share+0x985/0x2970 [cifs] ? check_path.constprop.0+0x28/0x50 ? save_trace+0x54/0x370 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? __lock_acquire+0xb82/0x2ba0 ? __kasan_check_write+0x18/0x20 cifs_mount+0xbc/0x9e0 [cifs] ? __pfx_cifs_mount+0x10/0x10 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_setup_cifs_sb+0x29d/0x810 [cifs] cifs_smb3_do_mount+0x263/0x1990 [cifs]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Validate UAC3 power domain descriptors, tooUAC3 power domain descriptors need to be verified with its variablebLength for avoiding the unexpected OOB accesses by maliciousfirmware, too.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/net: commit partial buffers on retryRing provided buffers are potentially only valid within the singleexecution context in which they were acquired. io_uring deals with thisand invalidates them on retry. But on the networking side, ifMSG_WAITALL is set, or if the socket is of the streaming type and toolittle was processed, then it will hang on to the buffer rather thanrecycle or commit it. This is problematic for two reasons:1) If someone unregisters the provided buffer ring before a later retry, then the req->buf_list will no longer be valid.2) If multiple sockers are using the same buffer group, then multiple receives can consume the same memory. This can cause data corruption in the application, as either receive could land in the same userspace buffer.Fix this by disallowing partial retries from pinning a provided bufferacross multiple executions, if ring provided buffers are used.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/mm: Do not map lowcore with identity mappingSince the identity mapping is pinned to address zero the lowcore is alwaysalso mapped to address zero, this happens regardless of the relocate_lowcorecommand line option. If the option is specified the lowcore is mappedtwice, instead of only once.This means that NULL pointer accesses will succeed instead of causing anexception (low address protection still applies, but covers only parts).To fix this never map the first two pages of physical memory with theidentity mapping.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: prevent ethtool ops after shutdownA crash can occur if an ethtool operation is invokedafter shutdown() is called.shutdown() is invoked during system shutdown to stop DMA operationswithout performing expensive deallocations. It is discouraged tounregister the netdev in this path, so the device may still be visibleto userspace and kernel helpers.In gve, shutdown() tears down most internal data structures. If anethtool operation is dispatched after shutdown(), it will dereferencefreed or NULL pointers, leading to a kernel panic. While gracefulshutdown normally quiesces userspace before invoking the rebootsyscall, forced shutdowns (as observed on GCP VMs) can still triggerthis path.Fix by calling netif_device_detach() in shutdown().This marks the device as detached so the ethtool ioctl handlerwill skip dispatching operations to the driver.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ppp: fix race conditions in ppp_fill_forward_pathppp_fill_forward_path() has two race conditions:1. The ppp->channels list can change between list_empty() and list_first_entry(), as ppp_lock() is not held. If the only channel is deleted in ppp_disconnect_channel(), list_first_entry() may access an empty head or a freed entry, and trigger a panic.2. pch->chan can be NULL. When ppp_unregister_channel() is called, pch->chan is set to NULL before pch is removed from ppp->channels.Fix these by using a lockless RCU approach:- Use list_first_or_null_rcu() to safely test and access the first list entry.- Convert list modifications on ppp->channels to their RCU variants and add synchronize_net() after removal.- Check for a NULL pch->chan before dereferencing it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null pointer check in mod_hdcp_hdcp1_create_session()The function mod_hdcp_hdcp1_create_session() calls the functionget_first_active_display(), but does not check its return value.The return value is a null pointer if the display list is empty.This will lead to a null pointer dereference.Add a null pointer check for get_first_active_display() and returnMOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.This is similar to the commit c3e9826a2202("drm/amd/display: Add null pointer check for get_first_active_display()").(cherry picked from commit 5e43eb3cd731649c4f8b9134f857be62a416c893)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla4xxx: Prevent a potential error pointer dereferenceThe qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,but qla4xxx_ep_connect() returns error pointers. Propagating the errorpointers will lead to an Oops in the caller, so change the error pointersto NULL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Fix backlog accounting in qdisc_dequeue_internalThis issue applies for the following qdiscs: hhf, fq, fq_codel, andfq_pie, and occurs in their change handlers when adjusting to the newlimit. The problem is the following in the values passed to thesubsequent qdisc_tree_reduce_backlog call given a tbf parent: When the tbf parent runs out of tokens, skbs of these qdiscs will be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued, which accounts for both qlen and backlog. However, in the case of qdisc_dequeue_internal, ONLY qlen is accounted for when pulling from gso_skb. This means that these qdiscs are missing a qdisc_qstats_backlog_dec when dropping packets to satisfy the new limit in their change handlers. One can observe this issue with the following (with tc patched to support a limit of 0): export TARGET=fq tc qdisc del dev lo root tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000 echo ''; echo 'add child'; tc -s -d qdisc show dev lo ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2>&1 >/dev/null echo ''; echo 'after ping'; tc -s -d qdisc show dev lo tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0 echo ''; echo 'after limit drop'; tc -s -d qdisc show dev lo tc qdisc replace dev lo handle 2: parent 1:1 sfq echo ''; echo 'post graft'; tc -s -d qdisc show dev lo The second to last show command shows 0 packets but a positive number (74) of backlog bytes. The problem becomes clearer in the last show command, where qdisc_purge_queue triggers qdisc_tree_reduce_backlog with the positive backlog and causes an underflow in the tbf parent's backlog (4096 Mb instead of 0).To fix this issue, the codepath for all clients of qdisc_dequeue_internalhas been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel.qdisc_dequeue_internal handles the backlog adjustments for all cases thatdo not directly use the dequeue handler.The old fq_codel_change limit adjustment loop accumulated the arguments tothe subsequent qdisc_tree_reduce_backlog call through the cstats field.However, this is confusing and error prone as fq_codel_dequeue could alsopotentially mutate this field (which qdisc_dequeue_internal calls in thenon gso_skb case), so we have unified the code here with other qdiscs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86/amd/hsmp: Ensure sock->metric_tbl_addr is non-NULLIf metric table address is not allocated, accessing metrics_bin willresult in a NULL pointer dereference, so add a check.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: rtl9300: Fix out-of-bounds bug in rtl9300_i2c_smbus_xferThe data->block[0] variable comes from user. Without proper check,the variable may be very large to cause an out-of-bounds bug.Fix this bug by checking the value of data->block[0] first.1. commit 39244cc75482 ("i2c: ismt: Fix an out-of-bounds bug in ismt_access()")2. commit 92fbb6d1296f ("i2c: xgene-slimpro: Fix out-of-bounds bug in xgene_slimpro_i2c_xfer()")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helperSince 923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot")resctrl_cpu_detect() has been moved from common CPU initialization code tothe vendor-specific BSP init helper, while Hygon didn't put that call in theircode.This triggers a division by zero fault during early booting stage on ourmachines with X86_FEATURE_CQM* supported, where get_rdt_mon_resources() triesto calculate mon_l3_config with uninitialized boot_cpu_data.x86_cache_occ_scale.Add the missing resctrl_cpu_detect() in the Hygon BSP init helper. [ bp: Massage commit message. ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Limit access to parser->buffer when trace_get_user failedWhen the length of the string written to set_ftrace_filter exceedsFTRACE_BUFF_MAX, the following KASAN alarm will be triggered:BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0Read of size 1 at addr ffff0000d00bd5ba by task ash/165CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirtyHardware name: linux,dummy-virt (DT)Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0The reason is that trace_get_user will fail when processing a stringlonger than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0.Then an OOB access will be triggered in ftrace_regex_release->ftrace_process_regex->strsep->strpbrk. We can solve this problem bylimiting access to parser->buffer when trace_get_user failed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl()syzbot reports a KMSAN kernel-infoleak in `do_insn_ioctl()`. A kernelbuffer is allocated to hold `insn->n` samples (each of which is an`unsigned int`). For some instruction types, `insn->n` samples arecopied back to user-space, unless an error code is being returned. Theproblem is that not all the instruction handlers that need to returndata to userspace fill in the whole `insn->n` samples, so that there isan information leak. There is a similar syzbot report for`do_insnlist_ioctl()`, although it does not have a reproducer for it atthe time of writing.One culprit is `insn_rw_emulate_bits()` which is used as the handler for`INSN_READ` or `INSN_WRITE` instructions for subdevices that do not havea specific handler for that instruction, but do have an `INSN_BITS`handler. For `INSN_READ` it only fills in at most 1 sample, so if`insn->n` is greater than 1, the remaining `insn->n - 1` samples copiedto userspace will be uninitialized kernel data.Another culprit is `vm80xx_ai_insn_read()` in the "vm80xx" driver. Itnever returns an error, even if it fails to fill the buffer.Fix it in `do_insn_ioctl()` and `do_insnlist_ioctl()` by making surethat uninitialized parts of the allocated buffer are zeroed beforehandling each instruction.Thanks to Arnaud Lecomte for their fix to `do_insn_ioctl()`. That fixreplaced the call to `kmalloc_array()` with `kcalloc()`, but it is notalways necessary to clear the whole buffer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Make insn_rw_emulate_bits() do insn->n samplesThe `insn_rw_emulate_bits()` function is used as a default handler for`INSN_READ` instructions for subdevices that have a handler for`INSN_BITS` but not for `INSN_READ`. Similarly, it is used as a defaulthandler for `INSN_WRITE` instructions for subdevices that have a handlerfor `INSN_BITS` but not for `INSN_WRITE`. It works by emulating the`INSN_READ` or `INSN_WRITE` instruction handling with a constructed`INSN_BITS` instruction. However, `INSN_READ` and `INSN_WRITE`instructions are supposed to be able read or write multiple samples,indicated by the `insn->n` value, but `insn_rw_emulate_bits()` currentlyonly handles a single sample. For `INSN_READ`, the comedi core willcopy `insn->n` samples back to user-space. (That triggered KASANkernel-infoleak errors when `insn->n` was greater than 1, but that isbeing fixed more generally elsewhere in the comedi core.)Make `insn_rw_emulate_bits()` either handle `insn->n` samples, or returnan error, to conform to the general expectation for `INSN_READ` and`INSN_WRITE` handlers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: as73211: Ensure buffer holes are zeroedGiven that the buffer is copied to a kfifo that ultimately user spacecan read, ensure we zero it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Also allocate and copy hash for reading of filter filesCurrently the reader of set_ftrace_filter and set_ftrace_notrace just addsthe pointer to the global tracer hash to its iterator. Unlike the writerthat allocates a copy of the hash, the reader keeps the pointer to thefilter hashes. This is problematic because this pointer is static acrossfunction calls that release the locks that can update the global tracerhashes. This can cause UAF and similar bugs.Allocate and copy the hash for reading the filter files like it is donefor the writers. This not only fixes UAF bugs, but also makes the code abit simpler as it doesn't have to differentiate when to free theiterator's hash between writers and readers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Avoid a NULL pointer dereference[WHY]Although unlikely drm_atomic_get_new_connector_state() ordrm_atomic_get_old_connector_state() can return NULL.[HOW]Check returns before dereference.(cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/sclp: Fix SCCB present checkTracing code called by the SCLP interrupt handler contains early exitsif the SCCB address associated with an interrupt is NULL. This check isperformed after physical to virtual address translation.If the kernel identity mapping does not start at address zero, theresulting virtual address is never zero, so that the NULL checks won'twork. Subsequently this may result in incorrect accesses to the firstpage of the identity mapping.Fix this by introducing a function that handles the NULL case beforeaddress translation.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix a race when updating an existing writeAfter nfs_lock_and_join_requests() tests for whether the request isstill attached to the mapping, nothing prevents a call tonfs_inode_remove_request() from succeeding until we actually lock thepage group.The reason is that whoever called nfs_inode_remove_request() doesn'tnecessarily have a lock on the page group head.So in order to avoid races, let's take the page group lock earlier innfs_lock_and_join_requests(), and hold it across the removal of therequest in nfs_inode_remove_request().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: pfr_update: Fix the driver update version checkThe security-version-number check should be used ratherthan the runtime version check for driver updates.Otherwise, the firmware update would fail when the update binary hada lower runtime version number than the current one.[ rjw: Changelog edits ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: Fix MAC comparison to be constant-timeTo prevent timing attacks, MACs need to be compared in constant time.Use the appropriate helper function for this.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:LoongArch: KVM: Fix stack protector issue in send_ipi_data()Function kvm_io_bus_read() is called in function send_ipi_data(), buffersize of parameter *val should be at least 8 bytes. Since some emulationfunctions like loongarch_ipi_readl() and kvm_eiointc_read() will writethe buffer *val with 8 bytes signed extension regardless parameter len.Otherwise there will be buffer overflow issue when CONFIG_STACKPROTECTORis enabled. The bug report is shown as follows:Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: send_ipi_data+0x194/0x1a0 [kvm]CPU: 11 UID: 107 PID: 2692 Comm: CPU 0/KVM Not tainted 6.17.0-rc1+ #102 PREEMPT(full)Stack : 9000000005901568 0000000000000000 9000000003af371c 900000013c68c000 900000013c68f850 900000013c68f858 0000000000000000 900000013c68f998 900000013c68f990 900000013c68f990 900000013c68f6c0 fffffffffffdb058 fffffffffffdb0e0 900000013c68f858 911e1d4d39cf0ec2 9000000105657a00 0000000000000001 fffffffffffffffe 0000000000000578 282049464555206e 6f73676e6f6f4c20 0000000000000001 00000000086b4000 0000000000000000 0000000000000000 0000000000000000 9000000005709968 90000000058f9000 900000013c68fa68 900000013c68fab4 90000000029279f0 900000010153f940 900000010001f360 0000000000000000 9000000003af3734 000000004390000c 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ...Call Trace:[<9000000003af3734>] show_stack+0x5c/0x180[<9000000003aed168>] dump_stack_lvl+0x6c/0x9c[<9000000003ad0ab0>] vpanic+0x108/0x2c4[<9000000003ad0ca8>] panic+0x3c/0x40[<9000000004eb0a1c>] __stack_chk_fail+0x14/0x18[] send_ipi_data+0x190/0x1a0 [kvm][] __kvm_io_bus_write+0xa4/0xe8 [kvm][] kvm_io_bus_write+0x54/0x90 [kvm][] kvm_emu_iocsr+0x180/0x310 [kvm][] kvm_handle_gspr+0x280/0x478 [kvm][] kvm_handle_exit+0xc0/0x130 [kvm]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: fix a Null pointer dereference vulnerability[Why]A null pointer dereference vulnerability exists in the AMD display driver's(DC module) cleanup function dc_destruct().When display control context (dc->ctx) construction fails(due to memory allocation failure), this pointer remains NULL.During subsequent error handling when dc_destruct() is called,there's no NULL check before dereferencing the perf_trace member(dc->ctx->perf_trace), causing a kernel null pointer dereference crash.[How]Check if dc->ctx is non-NULL before dereferencing.(Updated commit text and removed unnecessary error message)(cherry picked from commit 9dd8e2ba268c636c240a918e0a31e6feaee19404)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: protect against spurious interrupts during probeMake sure the interrupt handler is initialized before the interrupt isregistered.If the IRQ is registered before hfi_create(), it's possible that aninterrupt fires before the handler setup is complete, leading to a NULLdereference.This error condition has been observed during system boot on Rb3Gen2.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: Add a check for packet size after reading from shared memoryAdd a check to ensure that the packet size does not exceed the number ofavailable words after reading the packet header from shared memory. Thisensures that the size provided by the firmware is safe to process andprevent potential out-of-bounds memory access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: ivsc: Fix crash at shutdown due to missing mei_cldev_disable() callsBoth the ACE and CSI driver are missing a mei_cldev_disable() call intheir remove() function.This causes the mei_cl client to stay part of the mei_device->file_listlist even though its memory is freed by mei_cl_bus_dev_release() callingkfree(cldev->cl).This leads to a use-after-free when mei_vsc_remove() runs mei_stop()which first removes all mei bus devices calling mei_ace_remove() andmei_csi_remove() followed by mei_cl_bus_dev_release() and then callsmei_cl_all_disconnect() which walks over mei_device->file_list dereferecingthe just freed cldev->cl.And mei_vsc_remove() it self is run at shutdown because of theplatform_device_unregister(tp->pdev) in vsc_tp_shutdown()When building a kernel with KASAN this leads to the following KASAN report:[ 106.634504] ==================================================================[ 106.634623] BUG: KASAN: slab-use-after-free in mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei[ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1[ 106.634729][ 106.634767] Tainted: [E]=UNSIGNED_MODULE[ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025[ 106.634773] Call Trace:[ 106.634777] ...[ 106.634871] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)[ 106.634901] mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei[ 106.634921] mei_cl_all_disconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei[ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei...[ 106.635042] mei_stop (drivers/misc/mei/init.c:348) mei[ 106.635062] mei_vsc_remove (drivers/misc/mei/mei_dev.h:784 drivers/misc/mei/platform-vsc.c:393) mei_vsc[ 106.635066] platform_remove (drivers/base/platform.c:1424)Add the missing mei_cldev_disable() calls so that the mei_cl gets removedfrom mei_device->file_list before it is freed to fix this.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mt9m114: Fix deadlock in get_frame_interval/set_frame_intervalGetting / Setting the frame interval using the V4L2 subdev pad opsget_frame_interval/set_frame_interval causes a deadlock, as thesubdev state is locked in the [1] but also in the driver itself.In [2] it's described that the caller is responsible to acquire andrelease the lock in this case. Therefore, acquiring the lock in thedriver is wrong.Remove the lock acquisitions/releases from mt9m114_ifp_get_frame_interval()and mt9m114_ifp_set_frame_interval().[1] drivers/media/v4l2-core/v4l2-subdev.c - line 1129[2] Documentation/driver-api/media/v4l2-subdev.rst
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()In the interrupt handler rain_interrupt(), the buffer full check onrain->buf_len is performed before acquiring rain->buf_lock. Thiscreates a Time-of-Check to Time-of-Use (TOCTOU) race condition, asrain->buf_len is concurrently accessed and modified in the workhandler rain_irq_work_handler() under the same lock.Multiple interrupt invocations can race, with each reading buf_lenbefore it becomes full and then proceeding. This can lead to bothinterrupts attempting to write to the buffer, incrementing buf_lenbeyond its capacity (DATA_SIZE) and causing a buffer overflow.Fix this bug by moving the spin_lock() to before the buffer fullcheck. This ensures that the check and the subsequent buffer modificationare performed atomically, preventing the race condition. An correspondingspin_unlock() is added to the overflow path to correctly release thelock.This possible bug was found by an experimental static analysis tooldeveloped by our team.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: usbtv: Lock resolution while streamingWhen an program is streaming (ffplay) and another program (qv4l2)changes the TV standard from NTSC to PAL, the kernel crashes due to tryingto copy to unmapped memory.Changing from NTSC to PAL increases the resolution in the usbtv struct,but the video plane buffer isn't adjusted, so it overflows.[hverkuil: call vb2_is_busy instead of vb2_is_streaming]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: Validate length in packet header before skb_put()When receiving a vsock packet in the guest, only the virtqueue buffersize is validated prior to virtio_vsock_skb_rx_put(). Unfortunately,virtio_vsock_skb_rx_put() uses the length from the packet header as thelength argument to skb_put(), potentially resulting in SKB overflow ifthe host has gone wonky.Validate the length as advertised by the packet header before callingvirtio_vsock_skb_rx_put().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: imu: bno055: fix OOB access of hw_xlate arrayFix a potential out-of-bounds array access of the hw_xlate array inbno055.c.In bno055_get_regmask(), hw_xlate was iterated over the length of thevals array instead of the length of the hw_xlate array. In the case ofbno055_gyr_scale, the vals array is larger than the hw_xlate array,so this could result in an out-of-bounds access. In practice, thisshouldn't happen though because a match should always be found whichbreaks out of the for loop before it iterates beyond the end of thehw_xlate array.By adding a new hw_xlate_len field to the bno055_sysfs_attr, we can besure we are iterating over the correct length.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat - flush misc workqueue during device shutdownRepeated loading and unloading of a device specific QAT driver, forexample qat_4xxx, in a tight loop can lead to a crash due to ause-after-free scenario. This occurs when a power management (PM)interrupt triggers just before the device-specific driver (e.g.,qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remainsloaded.Since the driver uses a shared workqueue (`qat_misc_wq`) across alldevices and owned by intel_qat.ko, a deferred routine from thedevice-specific driver may still be pending in the queue. If thisroutine executes after the driver is unloaded, it can dereference freedmemory, resulting in a page fault and kernel crash like the following: BUG: unable to handle page fault for address: ffa000002e50a01c #PF: supervisor read access in kernel mode RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat] Call Trace: pm_bh_handler+0x1d2/0x250 [intel_qat] process_one_work+0x171/0x340 worker_thread+0x277/0x3a0 kthread+0xf0/0x120 ret_from_fork+0x2d/0x50To prevent this, flush the misc workqueue during device shutdown toensure that all pending work items are completed before the driver isunloaded.Note: This approach may slightly increase shutdown latency if theworkqueue contains jobs from other devices, but it ensures correctnessand stability.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: caam - Prevent crash on suspend with iMX8QM / iMX8ULPSince the CAAM on these SoCs is managed by another ARM core, called theSECO (Security Controller) on iMX8QM and Secure Enclave on iMX8ULP, whichalso reserves access to register page 0 suspend operations cannot touchthis page.This is similar to when running OPTEE, where OPTEE will reserve page 0.Track this situation using a new state variable no_page0, reflecting ifpage 0 is reserved elsewhere, either by other management cores in SoC orby OPTEE.Replace the optee_en check in suspend/resume with the new check.optee_en cannot go away as it's needed elsewhere to gate OPTEE specificsituations.Fixes the following splat at suspend: Internal error: synchronous external abort: 0000000096000010 [#1] SMP Hardware name: Freescale i.MX8QXP ACU6C (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : readl+0x0/0x18 lr : rd_reg32+0x18/0x3c sp : ffffffc08192ba20 x29: ffffffc08192ba20 x28: ffffff8025190000 x27: 0000000000000000 x26: ffffffc0808ae808 x25: ffffffc080922338 x24: ffffff8020e89090 x23: 0000000000000000 x22: ffffffc080922000 x21: ffffff8020e89010 x20: ffffffc080387ef8 x19: ffffff8020e89010 x18: 000000005d8000d5 x17: 0000000030f35963 x16: 000000008f785f3f x15: 000000003b8ef57c x14: 00000000c418aef8 x13: 00000000f5fea526 x12: 0000000000000001 x11: 0000000000000002 x10: 0000000000000001 x9 : 0000000000000000 x8 : ffffff8025190870 x7 : ffffff8021726880 x6 : 0000000000000002 x5 : ffffff80217268f0 x4 : ffffff8021726880 x3 : ffffffc081200000 x2 : 0000000000000001 x1 : ffffff8020e89010 x0 : ffffffc081200004 Call trace: readl+0x0/0x18 caam_ctrl_suspend+0x30/0xdc dpm_run_callback.constprop.0+0x24/0x5c device_suspend+0x170/0x2e8 dpm_suspend+0xa0/0x104 dpm_suspend_start+0x48/0x50 suspend_devices_and_enter+0x7c/0x45c pm_suspend+0x148/0x160 state_store+0xb4/0xf8 kobj_attr_store+0x14/0x24 sysfs_kf_write+0x38/0x48 kernfs_fop_write_iter+0xb4/0x178 vfs_write+0x118/0x178 ksys_write+0x6c/0xd0 __arm64_sys_write+0x14/0x1c invoke_syscall.constprop.0+0x64/0xb0 do_el0_svc+0x90/0xb0 el0_svc+0x18/0x44 el0t_64_sync_handler+0x88/0x124 el0t_64_sync+0x150/0x154 Code: 88dffc21 88dffc21 5ac00800 d65f03c0 (b9400000)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfs: Fix unbuffered write error handlingIf all the subrequests in an unbuffered write stream fail, the subrequestcollector doesn't update the stream->transferred value and it retains itsinitial LONG_MAX value. Unfortunately, if all active streams fail, then wetake the smallest value of { LONG_MAX, LONG_MAX, ... } as the value to setin wreq->transferred - which is then returned from ->write_iter().LONG_MAX was chosen as the initial value so that all the streams can bequickly assessed by taking the smallest value of all stream->transferred -but this only works if we've set any of them.Fix this by adding a flag to indicate whether the value instream->transferred is valid and checking that when we integrate thevalues. stream->transferred can then be initialised to zero.This was found by running the generic/750 xfstest against cifs withcache=none. It splices data to the target file. Once (if) it has used upall the available scratch space, the writes start failing with ENOSPC.This causes ->write_iter() to fail. However, it was returningwreq->transferred, i.e. LONG_MAX, rather than an error (because it thoughtthe amount transferred was non-zero) and iter_file_splice_write() wouldthen try to clean up that amount of pipe bufferage - leading to an oopswhen it overran. The kernel log showed: CIFS: VFS: Send error in write = -28followed by: BUG: kernel NULL pointer dereference, address: 0000000000000008with: RIP: 0010:iter_file_splice_write+0x3a4/0x520 do_splice+0x197/0x4e0or: RIP: 0010:pipe_buf_release (include/linux/pipe_fs_i.h:282) iter_file_splice_write (fs/splice.c:755)Also put a warning check into splice to announce if ->write_iter() returnedthat it had written more than it was asked to.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: 8250: fix panic due to PSLVERRWhen the PSLVERR_RESP_EN parameter is set to 1, the device generatesan error response if an attempt is made to read an empty RBR (ReceiveBuffer Register) while the FIFO is enabled.In serial8250_do_startup(), calling serial_port_out(port, UART_LCR,UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokesdw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latterfunction enables the FIFO via serial_out(p, UART_FCR, p->fcr).Execution proceeds to the serial_port_in(port, UART_RX).This satisfies the PSLVERR trigger condition.When another CPU (e.g., using printk()) is accessing the UART (UARTis busy), the current CPU fails the check (value & ~UART_LCR_SPAR) ==(lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enterdw8250_force_idle().Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lockto fix this issue.Panic backtrace:[ 0.442336] Oops - unknown exception [#1][ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a[ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e...[ 0.442416] console_on_rootfs+0x26/0x70
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: samsung: Fix UBSAN panic in samsung_clk_init()With UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due todereferencing `ctx->clk_data.hws` before setting`ctx->clk_data.num = nr_clks`. Move that up to fix the crash. UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP Call trace: samsung_clk_init+0x110/0x124 (P) samsung_clk_init+0x48/0x124 (L) samsung_cmu_register_one+0x3c/0xa0 exynos_arm64_register_cmu+0x54/0x64 __gs101_cmu_top_of_clk_init_declare+0x28/0x60 ...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix filehandle bounds checking in nfs_fh_to_dentry()The function needs to check the minimal filehandle length before it canaccess the embedded filehandle.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask()ath11k_mac_disable_peer_fixed_rate() is passed as the iterator toieee80211_iterate_stations_atomic(). Note in this case the iterator isrequired to be atomic, however ath11k_mac_disable_peer_fixed_rate() doesnot follow it as it might sleep. Consequently below warning is seen:BUG: sleeping function called from invalid context at wmi.c:304Call Trace: dump_stack_lvl __might_resched.cold ath11k_wmi_cmd_send ath11k_wmi_set_peer_param ath11k_mac_disable_peer_fixed_rate ieee80211_iterate_stations_atomic ath11k_mac_op_set_bitrate_mask.coldChange to ieee80211_iterate_stations_mtx() to fix this issue.Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Fix rcu_read_unlock() deadloop due to IRQ workDuring rcu_read_unlock_special(), if this happens during irq_exit(), wecan lockup if an IPI is issued. This is because the IPI itself triggersthe irq_exit() path causing a recursive lock up.This is precisely what Xiongfeng found when invoking a BPF program onthe trace_tick_stop() tracepoint As shown in the trace below. Fix bymanaging the irq_work state correctly.irq_exit() __irq_exit_rcu() /* in_hardirq() returns false after this */ preempt_count_sub(HARDIRQ_OFFSET) tick_irq_exit() tick_nohz_irq_exit() tick_nohz_stop_sched_tick() trace_tick_stop() /* a bpf prog is hooked on this trace point */ __bpf_trace_tick_stop() bpf_trace_run2() rcu_read_unlock_special() /* will send a IPI to itself */ irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu);A simple reproducer can also be obtained by doing the following intick_irq_exit(). It will hang on boot without the patch: static inline void tick_irq_exit(void) { + rcu_read_lock(); + WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true); + rcu_read_unlock(); +[neeraj: Apply Frederic's suggested fix for PREEMPT_RT]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Protect ->defer_qs_iw_pending from data raceOn kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() isinvoked within an interrupts-disabled region of code [1], it will invokercu_read_unlock_special(), which uses an irq-work handler to force thesystem to notice when the RCU read-side critical section actually ends.That end won't happen until interrupts are enabled at the soonest.In some kernels, such as those booted with rcutree.use_softirq=y, theirq-work handler is used unconditionally.The per-CPU rcu_data structure's ->defer_qs_iw_pending field isupdated by the irq-work handler and is both read and updated byrcu_read_unlock_special(). This resulted in the following KCSAN splat:------------------------------------------------------------------------BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_specialread to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcu_read_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0 __local_bh_enable+0x10d/0x170 __local_bh_enable_ip+0xfb/0x150 rcu_do_batch+0x595/0xc40 rcu_cpu_kthread+0x4e9/0x830 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcu_preempt_deferred_qs_handler+0x1e/0x30 irq_work_single+0xaf/0x160 run_irq_workd+0x91/0xc0 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30no locks held by irq_work/8/88.irq event stamp: 200272hardirqs last enabled at (200272): [] finish_task_switch+0x131/0x320hardirqs last disabled at (200271): [] __schedule+0x129/0xd70softirqs last enabled at (0): [] copy_process+0x4df/0x1cc0softirqs last disabled at (0): [<0000000000000000>] 0x0------------------------------------------------------------------------The problem is that irq-work handlers run with interrupts enabled, whichmeans that rcu_preempt_deferred_qs_handler() could be interrupted,and that interrupt handler might contain an RCU read-side criticalsection, which might invoke rcu_read_unlock_special(). In the strictKCSAN mode of operation used by RCU, this constitutes a data race onthe ->defer_qs_iw_pending field.This commit therefore disables interrupts across the portion of thercu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pendingfield. This suffices because this handler is not a fast path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/smaps: fix race between smaps_hugetlb_range and migrationsmaps_hugetlb_range() handles the pte without holdling ptl, and may beconcurrenct with migration, leaing to BUG_ON in pfn_swap_entry_to_page(). The race is as follows.smaps_hugetlb_range migrate_pages huge_ptep_get remove_migration_ptes folio_unlock pfn_swap_entry_folio BUG_ONTo fix it, hold ptl lock in smaps_hugetlb_range().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: Prevent file descriptor table allocations exceeding INT_MAXWhen sysctl_nr_open is set to a very high value (for example, 1073741816as set by systemd), processes attempting to use file descriptors nearthe limit can trigger massive memory allocation attempts that exceedINT_MAX, resulting in a WARNING in mm/slub.c: WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288This happens because kvmalloc_array() and kvmalloc() check if therequested size exceeds INT_MAX and emit a warning when the allocation isnot flagged with __GFP_NOWARN.Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and aprocess calls dup2(oldfd, 1073741880), the kernel attempts to allocate:- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes- Multiple bitmaps: ~400MB- Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647)Reproducer:1. Set /proc/sys/fs/nr_open to 1073741816: # echo 1073741816 > /proc/sys/fs/nr_open2. Run a program that uses a high file descriptor: #include #include int main() { struct rlimit rlim = {1073741824, 1073741824}; setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // Triggers the warning return 0; }3. Observe WARNING in dmesg at mm/slub.c:5027systemd commit a8b627a introduced automatic bumping of fs.nr_open to themaximum possible value. The rationale was that systems with memorycontrol groups (memcg) no longer need separate file descriptor limitssince memory is properly accounted. However, this change overlookedthat:1. The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of memcg accounting2. Programs and tests that legitimately test file descriptor limits can inadvertently trigger massive allocations3. The resulting allocations (>8GB) are impractical and will always failsystemd's algorithm starts with INT_MAX and keeps halving the valueuntil the kernel accepts it. On most systems, this results in nr_openbeing set to 1073741816 (0x3ffffff8), which is just under 1GB of filedescriptors.While processes rarely use file descriptors near this limit in normaloperation, certain selftests (liketools/testing/selftests/core/unshare_test.c) and programs that test filedescriptor limits can trigger this issue.Fix this by adding a check in alloc_fdtable() to ensure the requestedallocation size does not exceed INT_MAX. This causes the operation tofail with -EMFILE instead of triggering a kernel warning and avoids theimpractical >8GB memory allocation request.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Validate UAC3 cluster segment descriptorsUAC3 class segment descriptors need to be verified whether their sizesmatch with the declared lengths and whether they fit with theallocated buffer sizes, too. Otherwise malicious firmware may lead tothe unexpected OOB accesses.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpagesEver since commit c2ff29e99a76 ("siw: Inline do_tcp_sendpages()"),we have been doing this:static int siw_tcp_sendpages(struct socket *s, struct page **page, int offset, size_t size)[...] /* Calculate the number of bytes we need to push, for this page * specifically */ size_t bytes = min_t(size_t, PAGE_SIZE - offset, size); /* If we can't splice it, then copy it in, as normal */ if (!sendpage_ok(page[i])) msg.msg_flags &= ~MSG_SPLICE_PAGES; /* Set the bvec pointing to the page, with len $bytes */ bvec_set_page(&bvec, page[i], bytes, offset); /* Set the iter to $size, aka the size of the whole sendpages (!!!) */ iov_iter_bvec(&msg.msg_iter, ITER_SOURCE, &bvec, 1, size);try_page_again: lock_sock(sk); /* Sendmsg with $size size (!!!) */ rv = tcp_sendmsg_locked(sk, &msg, size);This means we've been sending oversized iov_iters and tcp_sendmsg callsfor a while. This has a been a benign bug because sendpage_ok() alwaysreturned true. With the recent slab allocator changes being slowlyintroduced into next (that disallow sendpage on large kmallocallocations), we have recently hit out-of-bounds crashes, due to slightdifferences in iov_iter behavior between the MSG_SPLICE_PAGES and"regular" copy paths:(MSG_SPLICE_PAGES)skb_splice_from_iter iov_iter_extract_pages iov_iter_extract_bvec_pages uses i->nr_segs to correctly stop in its tracks before OoB'ing everywhere skb_splice_from_iter gets a "short" read(!MSG_SPLICE_PAGES)skb_copy_to_page_nocache copy=iov_iter_count [...] copy_from_iter /* this doesn't help */ if (unlikely(iter->count < len)) len = iter->count; iterate_bvec ... and we run off the bvecsFix this by properly setting the iov_iter's byte count, plus sending thecorrect byte count to tcp_sendmsg_locked.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: remove refcounting in expectation dumpersSame pattern as previous patch: do not keep the expectation objectalive via refcount, only store a cookie value and then use thatas the skip hint for dump resumption.AFAICS this has the same issue as the one resolved in the conntrackdumper, when we do if (!refcount_inc_not_zero(&exp->use))to increment the refcount, there is a chance that exp == last, whichcauses a double-increment of the refcount and subsequent memory leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: timer: fix ida_free call while not allocatedIn the snd_utimer_create() function, if the kasprintf() function returnNULL, snd_utimer_put_id() will be called, finally use ida_free()to free the unallocated id 0.the syzkaller reported the following information: ------------[ cut here ]------------ ida_free called for id=0 which is not allocated. WARNING: CPU: 1 PID: 1286 at lib/idr.c:592 ida_free+0x1fd/0x2f0 lib/idr.c:592 Modules linked in: CPU: 1 UID: 0 PID: 1286 Comm: syz-executor164 Not tainted 6.15.8 #3 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014 RIP: 0010:ida_free+0x1fd/0x2f0 lib/idr.c:592 Code: f8 fc 41 83 fc 3e 76 69 e8 70 b2 f8 (...) RSP: 0018:ffffc900007f79c8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 1ffff920000fef3b RCX: ffffffff872176a5 RDX: ffff88800369d200 RSI: 0000000000000000 RDI: ffff88800369d200 RBP: 0000000000000000 R08: ffffffff87ba60a5 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f6f1abc1740(0000) GS:ffff8880d76a0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6f1ad7a784 CR3: 000000007a6e2000 CR4: 00000000000006f0 Call Trace: snd_utimer_put_id sound/core/timer.c:2043 [inline] [snd_timer] snd_utimer_create+0x59b/0x6a0 sound/core/timer.c:2184 [snd_timer] snd_utimer_ioctl_create sound/core/timer.c:2202 [inline] [snd_timer] __snd_timer_user_ioctl.isra.0+0x724/0x1340 sound/core/timer.c:2287 [snd_timer] snd_timer_user_ioctl+0x75/0xc0 sound/core/timer.c:2298 [snd_timer] vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x198/0x200 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x7b/0x160 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...]The utimer->id should be set properly before the kasprintf() function,ensures the snd_utimer_put_id() function will free the allocated id.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limitThe following setup can trigger a WARNING in htb_activate due tothe condition: !cl->leaf.q->q.qlentc qdisc del dev lo roottc qdisc add dev lo root handle 1: htb default 1tc class add dev lo parent 1: classid 1:1 \ htb rate 64bittc qdisc add dev lo parent 1:1 handle f: \ cake memlimit 1bping -I lo -f -c1 -s64 -W0.001 127.0.0.1This is because the low memlimit leads to a low buffer_limit, whichcauses packet dropping. However, cake_enqueue still returnsNET_XMIT_SUCCESS, causing htb_enqueue to call htb_activate with anempty child qdisc. We should return NET_XMIT_CN when packets aredropped from the same tin and flow.I do not believe return value of NET_XMIT_CN is necessary for packetdrops in the case of ack filtering, as that is meant to optimizeperformance, not to signal congestion.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/hisilicon/hibmc: fix the hibmc loaded failed bugWhen hibmc loaded failed, the driver use hibmc_unload to free theresource, but the mutexes in mode.config are not init, which willaccess an NULL pointer. Just change goto statement to return, becausehibnc_hw_init() doesn't need to free anything.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: fix soft lockup in br_multicast_query_expired()When set multicast_query_interval to a large value, the local variable'time' in br_multicast_send_query() may overflow. If the time is smallerthan jiffies, the timer will expire immediately, and then call mod_timer()again, which creates a loop and may trigger the following soft lockupissue. watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66] CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: __netdev_alloc_skb+0x2e/0x3a0 br_ip6_multicast_alloc_query+0x212/0x1b70 __br_multicast_send_query+0x376/0xac0 br_multicast_send_query+0x299/0x510 br_multicast_query_expired.constprop.0+0x16d/0x1b0 call_timer_fn+0x3b/0x2a0 __run_timers+0x619/0x950 run_timer_softirq+0x11c/0x220 handle_softirqs+0x18e/0x560 __irq_exit_rcu+0x158/0x1a0 sysvec_apic_timer_interrupt+0x76/0x90 This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicast_querier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicast_query_interval ip link set dev br0 upThe multicast_startup_query_interval can also cause this issue. Similar tothe commit 99b40610956a ("net: bridge: mcast: add and enforce queryinterval minimum"), add check for the query interval maximum to fix thisissue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mremap: fix WARN with uffd that has remap events disabledRegistering userfaultd on a VMA that spans at least one PMD and thenmremap()'ing that VMA can trigger a WARN when recovering from a failedpage table move due to a page table allocation error.The code ends up doing the right thing (recurse, avoiding moving actualpage tables), but triggering that WARN is unpleasant:WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_normal_pmd mm/mremap.c:357 [inline]WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_pgt_entry mm/mremap.c:595 [inline]WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_page_tables+0x3832/0x44a0 mm/mremap.c:852Modules linked in:CPU: 2 UID: 0 PID: 6133 Comm: syz.0.19 Not tainted 6.17.0-rc1-syzkaller-00004-g53e760d89498 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:move_normal_pmd mm/mremap.c:357 [inline]RIP: 0010:move_pgt_entry mm/mremap.c:595 [inline]RIP: 0010:move_page_tables+0x3832/0x44a0 mm/mremap.c:852Code: ...RSP: 0018:ffffc900037a76d8 EFLAGS: 00010293RAX: 0000000000000000 RBX: 0000000032930007 RCX: ffffffff820c6645RDX: ffff88802e56a440 RSI: ffffffff820c7201 RDI: 0000000000000007RBP: ffff888037728fc0 R08: 0000000000000007 R09: 0000000000000000R10: 0000000032930007 R11: 0000000000000000 R12: 0000000000000000R13: ffffc900037a79a8 R14: 0000000000000001 R15: dffffc0000000000FS: 000055556316a500(0000) GS:ffff8880d68bc000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b30863fff CR3: 0000000050171000 CR4: 0000000000352ef0Call Trace: copy_vma_and_data+0x468/0x790 mm/mremap.c:1215 move_vma+0x548/0x1780 mm/mremap.c:1282 mremap_to+0x1b7/0x450 mm/mremap.c:1406 do_mremap+0xfad/0x1f80 mm/mremap.c:1921 __do_sys_mremap+0x119/0x170 mm/mremap.c:1977 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f00d0b8ebe9Code: ...RSP: 002b:00007ffe5ea5ee98 EFLAGS: 00000246 ORIG_RAX: 0000000000000019RAX: ffffffffffffffda RBX: 00007f00d0db5fa0 RCX: 00007f00d0b8ebe9RDX: 0000000000400000 RSI: 0000000000c00000 RDI: 0000200000000000RBP: 00007ffe5ea5eef0 R08: 0000200000c00000 R09: 0000000000000000R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000002R13: 00007f00d0db5fa0 R14: 00007f00d0db5fa0 R15: 0000000000000005 The underlying issue is that we recurse during the original page tablemove, but not during the recovery move.Fix it by checking for both VMAs and performing the check before thepmd_none() sanity check.Add a new helper where we perform+document that check for the PMD and PUDlevel.Thanks to Harry for bisecting.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/debug_vm_pgtable: clear page table entries at destroy_args()The mm/debug_vm_pagetable test allocates manually page table entries forthe tests it runs, using also its manually allocated mm_struct. That initself is ok, but when it exits, at destroy_args() it fails to clear thoseentries with the *_clear functions.The problem is that leaves stale entries. If another process allocates anmm_struct with a pgd at the same address, it may end up running into thestale entry. This is happening in practice on a debug kernel withCONFIG_DEBUG_VM_PGTABLE=y, for example this is the output with some extradebugging I added (it prints a warning trace if pgtables_bytes goesnegative, in addition to the warning at check_mm() function):[ 2.539353] debug_vm_pgtable: [get_random_vaddr ]: random_vaddr is 0x7ea247140000[ 2.539366] kmem_cache info[ 2.539374] kmem_cachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508[ 2.539447] debug_vm_pgtable: [init_args ]: args->mm is 0x000000002267cc9e(...)[ 2.552800] WARNING: CPU: 5 PID: 116 at include/linux/mm.h:2841 free_pud_range+0x8bc/0x8d0[ 2.552816] Modules linked in:[ 2.552843] CPU: 5 UID: 0 PID: 116 Comm: modprobe Not tainted 6.12.0-105.debug_vm2.el10.ppc64le+debug #1 VOLUNTARY[ 2.552859] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910_062) hv:phyp pSeries[ 2.552872] NIP: c0000000007eef3c LR: c0000000007eef30 CTR: c0000000003d8c90[ 2.552885] REGS: c0000000622e73b0 TRAP: 0700 Not tainted (6.12.0-105.debug_vm2.el10.ppc64le+debug)[ 2.552899] MSR: 800000000282b033 CR: 24002822 XER: 0000000a[ 2.552954] CFAR: c0000000008f03f0 IRQMASK: 0[ 2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00 0000000000000001[ 2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff[ 2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000[ 2.552954] GPR12: 00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb[ 2.552954] GPR16: 0000000000000000 0000000000000008 000000000000000a 60000000000000e0[ 2.552954] GPR20: 4080000000000000 c0000000113af038 00007fffcf130000 0000700000000000[ 2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000 0000000000000001[ 2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760[ 2.553170] NIP [c0000000007eef3c] free_pud_range+0x8bc/0x8d0[ 2.553185] LR [c0000000007eef30] free_pud_range+0x8b0/0x8d0[ 2.553199] Call Trace:[ 2.553207] [c0000000622e7650] [c0000000007eef30] free_pud_range+0x8b0/0x8d0 (unreliable)[ 2.553229] [c0000000622e7750] [c0000000007f40b4] free_pgd_range+0x284/0x3b0[ 2.553248] [c0000000622e7800] [c0000000007f4630] free_pgtables+0x450/0x570[ 2.553274] [c0000000622e78e0] [c0000000008161c0] exit_mmap+0x250/0x650[ 2.553292] [c0000000622e7a30] [c0000000001b95b8] __mmput+0x98/0x290[ 2.558344] [c0000000622e7a80] [c0000000001d1018] exit_mm+0x118/0x1b0[ 2.558361] [c0000000622e7ac0] [c0000000001d141c] do_exit+0x2ec/0x870[ 2.558376] [c0000000622e7b60] [c0000000001d1ca8] do_group_exit+0x88/0x150[ 2.558391] [c0000000622e7bb0] [c0000000001d1db8] sys_exit_group+0x48/0x50[ 2.558407] [c0000000622e7be0] [c00000000003d810] system_call_exception+0x1e0/0x4c0[ 2.558423] [c0000000622e7e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec(...)[ 2.558892] ---[ end trace 0000000000000000 ]---[ 2.559022] BUG: Bad rss-counter state mm:000000002267cc9e type:MM_ANONPAGES val:1[ 2.559037] BUG: non-zero pgtables_bytes on freeing mm: -6144Here the modprobe process ended up with an allocated mm_struct from themm_struct slab that was used before by the debug_vm_pgtable test. That isnot a problem, since the mm_stru---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: subpage: keep TOWRITE tag until folio is cleanedbtrfs_subpage_set_writeback() calls folio_start_writeback() the first timea folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tageven if there are still dirty blocks in the folio. This can break orderingguarantees, such as those required by btrfs_wait_ordered_extents().That ordering breakage leads to a real failure. For example, runninggeneric/464 on a zoned setup will hit the following ASSERT. This happensbecause the broken ordering fails to flush existing dirty pages before thefile size is truncated. assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899 ------------[ cut here ]------------ kernel BUG at fs/btrfs/zoned.c:1899! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs] RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246 RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8 R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00 R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680 FS: 0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0 Call Trace: ? srso_return_thunk+0x5/0x5f btrfs_finish_ordered_io+0x4a/0x60 [btrfs] btrfs_work_helper+0xf9/0x490 [btrfs] process_one_work+0x204/0x590 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d6/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x118/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x205/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode orfor compressed writes, it locks several folios for delalloc and startswriting them out. Let's call the last locked folio folio X. Suppose thewrite range only partially covers folio X, leaving some pages dirty.Process A calls btrfs_subpage_set_writeback() when building a bio. Thisfunction call clears the TOWRITE tag of folio X, whose size = 8K andthe block size = 4K. It is following state. 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY) <-----> Process A will write this range.Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. Itcalls tag_pages_for_writeback() to tag dirty folios withPAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then,B collects tagged folios using filemap_get_folios_tag() and must wait forfolio X to be written before returning from writepages(). 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY|TOWRITE)However, between tagging and collecting, process A may callbtrfs_subpage_set_writeback() and clear folio X's TOWRITE tag. 0 4K 8K | |/////| (flag: DIRTY|WRITEBACK, tag: DIRTY)As a result, process B won't see folio X in its batch, and returns withoutwaiting for it. This breaks the WB_SYNC_ALL ordering requirement.Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retainsthe TOWRITE tag. We now manually clear the tag only after the folio becomesclean, via the xas operation.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: prevent softlockup in jbd2_log_do_checkpoint()Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()periodically release j_list_lock after processing a batch of buffers toavoid long hold times on the j_list_lock. However, since both functionscontend for j_list_lock, the combined time spent waiting and processingcan be significant.jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() whenneed_resched() is true to avoid softlockups during prolonged operations.But jbd2_log_do_checkpoint() only exits its loop when need_resched() istrue, relying on potentially sleeping functions like __flush_batch() orwait_on_buffer() to trigger rescheduling. If those functions do not sleep,the kernel may hit a softlockup.watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017Workqueue: writeback wb_workfn (flush-7:2)pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : native_queued_spin_lock_slowpath+0x358/0x418lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]Call trace: native_queued_spin_lock_slowpath+0x358/0x418 jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2] add_transaction_credits+0x3bc/0x418 [jbd2] start_this_handle+0xf8/0x560 [jbd2] jbd2__journal_start+0x118/0x228 [jbd2] __ext4_journal_start_sb+0x110/0x188 [ext4] ext4_do_writepages+0x3dc/0x740 [ext4] ext4_writepages+0xa4/0x190 [ext4] do_writepages+0x94/0x228 __writeback_single_inode+0x48/0x318 writeback_sb_inodes+0x204/0x590 __writeback_inodes_wb+0x54/0xf8 wb_writeback+0x2cc/0x3d8 wb_do_writeback+0x2e0/0x2f8 wb_workfn+0x80/0x2a8 process_one_work+0x178/0x3e8 worker_thread+0x234/0x3b8 kthread+0xf0/0x108 ret_from_fork+0x10/0x20So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoidsoftlockup.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: Fix configfs group list head handlingDoing a list_del() on the epf_group field of struct pci_epf_driver inpci_epf_remove_cfs() is not correct as this field is a list head, nota list entry. This list_del() call triggers a KASAN warning when anendpoint function driver which has a configfs attribute group is torndown:==================================================================BUG: KASAN: slab-use-after-free in pci_epf_remove_cfs+0x17c/0x198Write of size 8 at addr ffff00010f4a0d80 by task rmmod/319CPU: 3 UID: 0 PID: 319 Comm: rmmod Not tainted 6.16.0-rc2 #1 NONEHardware name: Radxa ROCK 5B (DT)Call trace:show_stack+0x2c/0x84 (C)dump_stack_lvl+0x70/0x98print_report+0x17c/0x538kasan_report+0xb8/0x190__asan_report_store8_noabort+0x20/0x2cpci_epf_remove_cfs+0x17c/0x198pci_epf_unregister_driver+0x18/0x30nvmet_pci_epf_cleanup_module+0x24/0x30 [nvmet_pci_epf]__arm64_sys_delete_module+0x264/0x424invoke_syscall+0x70/0x260el0_svc_common.constprop.0+0xac/0x230do_el0_svc+0x40/0x58el0_svc+0x48/0xdcel0t_64_sync_handler+0x10c/0x138el0t_64_sync+0x198/0x19c...Remove this incorrect list_del() call from pci_epf_remove_cfs().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: x86/aegis - Add missing error checksThe skcipher_walk functions can allocate memory and can fail, sochecking for errors is necessary.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ARM: tegra: Use I/O memcpy to write to IRAMKasan crashes the kernel trying to check boundaries when using thenormal memcpy.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: avoid possible overflow for chunk_sectors check in blk_stack_limits()In blk_stack_limits(), we check that the t->chunk_sectors value is amultiple of the t->physical_block_size value.However, by finding the chunk_sectors value in bytes, we may overflowthe unsigned int which holds chunk_sectors, so change the check to bebased on sectors.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: abort transaction on unexpected eb generation at btrfs_copy_root()If we find an unexpected generation for the extent buffer we are cloningat btrfs_copy_root(), we just WARN_ON() and don't error out and abort thetransaction, meaning we allow to persist metadata with an unexpectedgeneration. Instead of warning only, abort the transaction and return-EUCLEAN.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Remove WARN_ON_ONCE() call from ufshcd_uic_cmd_compl()The UIC completion interrupt may be disabled while an UIC command isbeing processed. When the UIC completion interrupt is reenabled, an UICinterrupt is triggered and the WARN_ON_ONCE(!cmd) statement is hit.Hence this patch that removes this kernel warning.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: macb: fix unregister_netdev call order in macb_remove()When removing a macb device, the driver calls phy_exit() beforeunregister_netdev(). This leads to a WARN from kernfs: ------------[ cut here ]------------ kernfs: can not remove 'attached_dev', no directory WARNING: CPU: 1 PID: 27146 at fs/kernfs/dir.c:1683 Call trace: kernfs_remove_by_name_ns+0xd8/0xf0 sysfs_remove_link+0x24/0x58 phy_detach+0x5c/0x168 phy_disconnect+0x4c/0x70 phylink_disconnect_phy+0x6c/0xc0 [phylink] macb_close+0x6c/0x170 [macb] ... macb_remove+0x60/0x168 [macb] platform_remove+0x5c/0x80 ...The warning happens because the PHY is being exited while the netdevis still registered. The correct order is to unregister the netdevbefore shutting down the PHY and cleaning up the MDIO bus.Fix this by moving unregister_netdev() ahead of phy_exit() inmacb_remove().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: multitouch: fix slab out-of-bounds access in mt_report_fixup()A malicious HID device can trigger a slab out-of-bounds duringmt_report_fixup() by passing in report descriptor smaller than607 bytes. mt_report_fixup() attempts to patch byte offset 607of the descriptor with 0x25 by first checking if byte offset607 is 0x15 however it lacks bounds checks to verify if thedescriptor is big enough before conducting this check. Fixthis bug by ensuring the descriptor size is at least 608bytes before accessing it.Below is the KASAN splat after the out of bounds access happens:[ 13.671954] ==================================================================[ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110[ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10[ 13.673297][ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3[ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04[ 13.673297] Call Trace:[ 13.673297] [ 13.673297] dump_stack_lvl+0x5f/0x80[ 13.673297] print_report+0xd1/0x660[ 13.673297] kasan_report+0xe5/0x120[ 13.673297] __asan_report_load1_noabort+0x18/0x20[ 13.673297] mt_report_fixup+0x103/0x110[ 13.673297] hid_open_report+0x1ef/0x810[ 13.673297] mt_probe+0x422/0x960[ 13.673297] hid_device_probe+0x2e2/0x6f0[ 13.673297] really_probe+0x1c6/0x6b0[ 13.673297] __driver_probe_device+0x24f/0x310[ 13.673297] driver_probe_device+0x4e/0x220[ 13.673297] __device_attach_driver+0x169/0x320[ 13.673297] bus_for_each_drv+0x11d/0x1b0[ 13.673297] __device_attach+0x1b8/0x3e0[ 13.673297] device_initial_probe+0x12/0x20[ 13.673297] bus_probe_device+0x13d/0x180[ 13.673297] device_add+0xe3a/0x1670[ 13.673297] hid_add_device+0x31d/0xa40[...]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()in ntrig_report_version(), hdev parameter passed from hid_probe().sending descriptor to /dev/uhid can make hdev->dev.parent->parent to nullif hdev->dev.parent->parent is null, usb_dev hasinvalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returnedwhen usb_rcvctrlpipe() use usb_dev,it triggerpage fault error for address(0xffffffffffffff58)add null check logic to ntrig_report_version()before calling hid_to_usb_dev()
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix memory corruption when FW resources change during ifdownbnxt_set_dflt_rings() assumes that it is always called before any TC hasbeen created. So it doesn't take bp->num_tc into account and assumesthat it is always 0 or 1.In the FW resource or capability change scenario, the FW will returnflags in bnxt_hwrm_if_change() that will cause the driver toreinitialize and call bnxt_cancel_reservations(). This will lead tobnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tcmay be greater than 1. This will cause bp->tx_ring[] to be sized toosmall and cause memory corruption in bnxt_alloc_cp_rings().Fix it by properly scaling the TX rings by bp->num_tc in the codepaths mentioned above. Add 2 helper functions to determinebp->tx_nr_rings and bp->tx_nr_rings_per_tc.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix potential warning in trace_printk_seq during ftrace_dumpWhen calling ftrace_dump_one() concurrently with reading trace_pipe,a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a racecondition.The issue occurs because:CPU0 (ftrace_dump) CPU1 (reader)echo z > /proc/sysrq-trigger!trace_empty(&iter)trace_iterator_reset(&iter) <- len = size = 0 cat /sys/kernel/tracing/trace_pipetrace_find_next_entry_inc(&iter) __find_next_entry ring_buffer_empty_cpu <- all empty return NULLtrace_printk_seq(&iter.seq) WARN_ON_ONCE(s->seq.len >= s->seq.size)In the context between trace_empty() and trace_find_next_entry_inc()during ftrace_dump, the ring buffer data was consumed by other readers.This caused trace_find_next_entry_inc to return NULL, failing to populate`iter.seq`. At this point, due to the prior trace_iterator_reset, both`iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal,the WARN_ON_ONCE condition is triggered.Move the trace_printk_seq() into the if block that checks to make sure thereturn value of trace_find_next_entry_inc() is non-NULL inftrace_dump_one(), ensuring the 'iter.seq' is properly populated beforesubsequent operations.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/kbuf: always use READ_ONCE() to read ring provided buffer lengthsSince the buffers are mapped from userspace, it is prudent to useREAD_ONCE() to read the value into a local variable, and use that forany other actions taken. Having a stable read of the buffer lengthavoids worrying about it changing after checking, or being read multipletimes.Similarly, the buffer may well change in between it being picked andbeing committed. Ensure the looping for incremental ring buffer commitstops if it hits a zero sized buffer, as no further progress can be madeat that point.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:efivarfs: Fix slab-out-of-bounds in efivarfs_d_compareObserved on kernel 6.6 (present on master as well): BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can becomenegative, leadings to oob. The issue can be triggered by parallellookups using invalid filename: T1 T2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list lookup_open d_alloc_parallel __d_lookup_rcu __d_lookup_rcu_op_compare hlist_bl_for_each_entry_rcu // invalid dentry can be retrieved ->d_compare efivarfs_d_compare // oobFix it by checking 'guid' before cmp.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs/smb: Fix inconsistent refcnt updateA possible inconsistent update of refcount was identified in `smb2_compound_op`.Such inconsistent update could lead to possible resource leaks.Why it is a possible bug:1. In the comment section of the function, it clearly states that thereference to `cfile` should be dropped after calling this function.2. Every control flow path would check and drop the reference to`cfile`, except the patched one.3. Existing callers would not handle refcount update of `cfile` if-ENOMEM is returned.To fix the bug, an extra goto label "out" is added, to make sure that thecleanup logic would always be respected. As the problem is caused by theallocation failure of `vars`, the cleanup logic between label "finished"and "out" can be safely ignored. According to the definition of function`is_replayable_error`, the error code of "-ENOMEM" is not recoverable.Therefore, the replay logic also gets ignored.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/kbuf: fix signedness in this_len calculationWhen importing and using buffers, buf->len is considered unsigned.However, buf->len is converted to signed int when committing. This canlead to unexpected behavior if the buffer is large enough to beinterpreted as a negative value. Make min_t calculation unsigned.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().syzbot reported the splat below. [0]When atmtcp_v_open() or atmtcp_v_close() is called via connect()or close(), atmtcp_send_control() is called to send an in-kernelspecial message.The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length.Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.The notable thing is struct atmtcp_control is uAPI but has aspace for an in-kernel pointer. struct atmtcp_control { struct atmtcp_hdr hdr; /* must be first */ ... atm_kptr_t vcc; /* both directions */ ... } __ATM_API_ALIGN; typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;The special message is processed in atmtcp_recv_control() calledfrom atmtcp_c_send().atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths: 1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2. vcc_sendmsg()The problem is sendmsg() does not validate the message length anduserspace can abuse atmtcp_recv_control() to overwrite any kptrby atmtcp_control.Let's add a new ->pre_send() hook to validate messages from sendmsg().[0]:Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTIKASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f]CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline]RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4cRSP: 0018:ffffc90003f5f810 EFLAGS: 00010203RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068cRBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0ddR10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffffFS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0Call Trace: vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 ____sys_sendmsg+0x505/0x830 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f8d7e96a4a9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702fR10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10acR13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250 Modules linked in:
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:trace/fgraph: Fix the warning caused by missing unregister notifierThis warning was triggered during testing on v6.16:notifier callback ftrace_suspend_notifier_call already registeredWARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0...Call Trace: blocking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7fWhen writing to the function_profile_enabled interface, the notifier wasnot unregistered after start_graph_tracing failed, causing a warning thenext time function_profile_enabled was written.Fixed by adding unregister_pm_notifier in the exception path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: HWS, Fix memory leak in hws_pool_buddy_init error pathIn the error path of hws_pool_buddy_init(), the buddy allocator cleanupdoesn't free the allocator structure itself, causing a memory leak.Add the missing kfree() to properly release all allocated memory.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbnic: Move phylink resume out of service_task and into open/closeThe fbnic driver was presenting with the following locking assert comingout of a PM resume:[ 42.208116][ T164] RTNL: assertion failed at drivers/net/phy/phylink.c (2611)[ 42.208492][ T164] WARNING: CPU: 1 PID: 164 at drivers/net/phy/phylink.c:2611 phylink_resume+0x190/0x1e0[ 42.208872][ T164] Modules linked in:[ 42.209140][ T164] CPU: 1 UID: 0 PID: 164 Comm: bash Not tainted 6.17.0-rc2-virtme #134 PREEMPT(full)[ 42.209496][ T164] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014[ 42.209861][ T164] RIP: 0010:phylink_resume+0x190/0x1e0[ 42.210057][ T164] Code: 83 e5 01 0f 85 b0 fe ff ff c6 05 1c cd 3e 02 01 90 ba 33 0a 00 00 48 c7 c6 20 3a 1d a5 48 c7 c7 e0 3e 1d a5 e8 21 b8 90 fe 90 <0f> 0b 90 90 e9 86 fe ff ff e8 42 ea 1f ff e9 e2 fe ff ff 48 89 ef[ 42.210708][ T164] RSP: 0018:ffffc90000affbd8 EFLAGS: 00010296[ 42.210983][ T164] RAX: 0000000000000000 RBX: ffff8880078d8400 RCX: 0000000000000000[ 42.211235][ T164] RDX: 0000000000000000 RSI: 1ffffffff4f10938 RDI: 0000000000000001[ 42.211466][ T164] RBP: 0000000000000000 R08: ffffffffa2ae79ea R09: fffffbfff4b3eb84[ 42.211707][ T164] R10: 0000000000000003 R11: 0000000000000000 R12: ffff888007ad8000[ 42.211997][ T164] R13: 0000000000000002 R14: ffff888006a18800 R15: ffffffffa34c59e0[ 42.212234][ T164] FS: 00007f0dc8e39740(0000) GS:ffff88808f51f000(0000) knlGS:0000000000000000[ 42.212505][ T164] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 42.212704][ T164] CR2: 00007f0dc8e9fe10 CR3: 000000000b56d003 CR4: 0000000000772ef0[ 42.213227][ T164] PKRU: 55555554[ 42.213366][ T164] Call Trace:[ 42.213483][ T164] [ 42.213565][ T164] __fbnic_pm_attach.isra.0+0x8e/0xa0[ 42.213725][ T164] pci_reset_function+0x116/0x1d0[ 42.213895][ T164] reset_store+0xa0/0x100[ 42.214025][ T164] ? pci_dev_reset_attr_is_visible+0x50/0x50[ 42.214221][ T164] ? sysfs_file_kobj+0xc1/0x1e0[ 42.214374][ T164] ? sysfs_kf_write+0x65/0x160[ 42.214526][ T164] kernfs_fop_write_iter+0x2f8/0x4c0[ 42.214677][ T164] ? kernfs_vma_page_mkwrite+0x1f0/0x1f0[ 42.214836][ T164] new_sync_write+0x308/0x6f0[ 42.214987][ T164] ? __lock_acquire+0x34c/0x740[ 42.215135][ T164] ? new_sync_read+0x6f0/0x6f0[ 42.215288][ T164] ? lock_acquire.part.0+0xbc/0x260[ 42.215440][ T164] ? ksys_write+0xff/0x200[ 42.215590][ T164] ? perf_trace_sched_switch+0x6d0/0x6d0[ 42.215742][ T164] vfs_write+0x65e/0xbb0[ 42.215876][ T164] ksys_write+0xff/0x200[ 42.215994][ T164] ? __ia32_sys_read+0xc0/0xc0[ 42.216141][ T164] ? do_user_addr_fault+0x269/0x9f0[ 42.216292][ T164] ? rcu_is_watching+0x15/0xd0[ 42.216442][ T164] do_syscall_64+0xbb/0x360[ 42.216591][ T164] entry_SYSCALL_64_after_hwframe+0x4b/0x53[ 42.216784][ T164] RIP: 0033:0x7f0dc8ea9986A bit of digging showed that we were invoking the phylink_resume as a partof the fbnic_up path when we were enabling the service task while notholding the RTNL lock. We should be enabling this sooner as a part of thendo_open path and then just letting the service task come online later.This will help to enforce the correct locking and brings the phylinkinterface online at the same time as the network interface, instead of at alater time.I tested this on QEMU to verify this was working by putting the system tosleep using "echo mem > /sys/power/state" to put the system to sleep in theguest and then using the command "system_wakeup" in the QEMU monitor.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mISDN: hfcpci: Fix warning when deleting uninitialized timerWith CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leadsto the following splat:[ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0[ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0[ 250.218775] Modules linked in: hfcpci(-) mISDN_core[ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary)[ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0[ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d[ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286[ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95[ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0[ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39[ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001[ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8[ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000[ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0[ 250.236117] Call Trace:[ 250.236599] [ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130[ 250.237920] debug_object_assert_init+0x1f6/0x310[ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10[ 250.239658] ? __lock_acquire+0xdea/0x1c70[ 250.240369] __try_to_del_timer_sync+0x69/0x140[ 250.241172] ? __pfx___try_to_del_timer_sync+0x10/0x10[ 250.242058] ? __timer_delete_sync+0xc6/0x120[ 250.242842] ? lock_acquire+0x30/0x80[ 250.243474] ? __timer_delete_sync+0xc6/0x120[ 250.244262] __timer_delete_sync+0x98/0x120[ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci][ 250.245704] __do_sys_delete_module+0x348/0x510[ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10[ 250.247338] do_syscall_64+0xc1/0x360[ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7fFix this by initializing hfc_tl timer with DEFINE_TIMER macro.Also, use mod_timer instead of manual timeout update.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: HWS, Fix memory leak in hws_action_get_shared_stc_nic error flowWhen an invalid stc_type is provided, the function allocates memory forshared_stc but jumps to unlock_and_out without freeing it, causing amemory leak.Fix by jumping to free_shared_stc label instead to ensure proper cleanup.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: do not propagate ENODATA disk errors into xattr codeENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code;namely, that the requested attribute name could not be found.However, a medium error from disk may also return ENODATA. At best,this medium error may escape to userspace as "attribute not found"when in fact it's an IO (disk) error.At worst, we may oops in xfs_attr_leaf_get() when we do: error = xfs_attr_leaf_hasname(args, &bp); if (error == -ENOATTR) { xfs_trans_brelse(args->trans, bp); return error; }because an ENODATA/ENOATTR error from disk leaves us with a null bp,and the xfs_trans_brelse will then null-deref it.As discussed on the list, we really need to modify the lower levelIO functions to trap all disk errors and ensure that we don't letunique errors like this leak up into higher xfs functions - manylike this should be remapped to EIO.However, this patch directly addresses a reported bug in the xattrcode, and should be safe to backport to stable kernels. A larger-scopepatch to handle more unique errors at lower levels can follow later.(Note, prior to 07120f1abdff we did not oops, but we did return thewrong error code to userspace.)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: fix OOB read/write in network-coding decodebatadv_nc_skb_decode_packet() trusts coded_len and checks only againstskb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducingpayload headroom, and the source skb length is not verified, allowing anout-of-bounds read and a small out-of-bounds write.Validate that coded_len fits within the payload area of both destinationand source sk_buffs before XORing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix buffer free/clear order in deferred receive pathFix a use-after-free window by correcting the buffer release sequence inthe deferred receive path. The code freed the RQ buffer first and onlythen cleared the context pointer under the lock. Concurrent paths (e.g.,ABTS and the repost path) also inspect and release the same pointer underthe lock, so the old order could lead to double-free/UAF.Note that the repost path already uses the correct pattern: detach thepointer under the lock, then free it after dropping the lock. Thedeferred path should do the same.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: prevent release journal inode after journal shutdownBefore calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has alreadybeen executed in ocfs2_dismount_volume(), so osb->journal must be NULL. Therefore, the following calltrace will inevitably fail when it reachesjbd2_journal_release_jbd_inode().ocfs2_dismount_volume()-> ocfs2_delete_osb()-> ocfs2_free_slot_info()-> __ocfs2_free_slot_info()-> evict()-> ocfs2_evict_inode()-> ocfs2_clear_inode()-> jbd2_journal_release_jbd_inode(osb->journal->j_journal,Adding osb->journal checks will prevent null-ptr-deref during the aboveexecution path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: slub: avoid wake up kswapd in set_track_prepareset_track_prepare() can incur lock recursion.The issue is that it is called from hrtimer_start_range_nsholding the per_cpu(hrtimer_bases)[n].lock, but when enabledCONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare,and try to hold the per_cpu(hrtimer_bases)[n].lock.Avoid deadlock caused by implicitly waking up kswapd by passing inallocation flags, which do not contain __GFP_KSWAPD_RECLAIM in thedebug_objects_fill_pool() case. Inside stack depot they are processed bygfp_nested_mask().Since ___slab_alloc() has preemption disabled, we mask out__GFP_DIRECT_RECLAIM from the flags there.The oops looks something like:BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT)Call trace:spin_bug+0x0_raw_spin_lock_irqsave+0x80hrtimer_try_to_cancel+0x94task_contending+0x10cenqueue_dl_entity+0x2a4dl_server_start+0x74enqueue_task_fair+0x568enqueue_task+0xacdo_activate_task+0x14cttwu_do_activate+0xcctry_to_wake_up+0x6c8default_wake_function+0x20autoremove_wake_function+0x1c__wake_up+0xacwakeup_kswapd+0x19cwake_all_kswapds+0x78__alloc_pages_slowpath+0x1ac__alloc_pages_noprof+0x298stack_depot_save_flags+0x6b0stack_depot_save+0x14set_track_prepare+0x5c___slab_alloc+0xccc__kmalloc_cache_noprof+0x470__set_page_owner+0x2bcpost_alloc_hook[jt]+0x1b8prep_new_page+0x28get_page_from_freelist+0x1edc__alloc_pages_noprof+0x13calloc_slab_page+0x244allocate_slab+0x7c___slab_alloc+0x8e8kmem_cache_alloc_noprof+0x450debug_objects_fill_pool+0x22cdebug_object_activate+0x40enqueue_hrtimer[jt]+0xdchrtimer_start_range_ns+0x5f8...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: move page table sync declarations to linux/pgtable.hDuring our internal testing, we started observing intermittent bootfailures when the machine uses 4-level paging and has a large amount ofpersistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] It turns out that the kernel panics while initializing vmemmap (structpage array) when the vmemmap region spans two PGD entries, because the newPGD entry is only installed in init_mm.pgd, but not in the page tables ofother tasks.And looking at __populate_section_memmap(): if (vmemmap_can_optimize(altmap, pgmap)) // does not sync top level page tables r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); else // sync top level page tables in x86 r = vmemmap_populate(start, end, nid, altmap);In the normal path, vmemmap_populate() in arch/x86/mm/init_64.csynchronizes the top level page table (See commit 9b861528a801 ("x86-64,mem: Update all PGDs for direct mapping and vmemmap mapping changes")) sothat all tasks in the system can see the new vmemmap area.However, when vmemmap_can_optimize() returns true, the optimized pathskips synchronization of top-level page tables. This is becausevmemmap_populate_compound_pages() is implemented in core MM code, whichdoes not handle synchronization of the top-level page tables. Instead,the core MM has historically relied on each architecture to perform thissynchronization manually.We're not the first party to encounter a crash caused by not-sync'd toplevel page tables: earlier this year, Gwan-gyeong Mun attempted to addressthe issue [1] [2] after hitting a kernel panic when x86 code accessed thevmemmap area before the corresponding top-level entries were synced. Atthat time, the issue was believed to be triggered only when struct pagewas enlarged for debugging purposes, and the patch did not get furtherupdates.It turns out that current approach of relying on each arch to handle thepage table sync manually is fragile because 1) it's easy to forget to syncthe top level page table, and 2) it's also easy to overlook that thekernel should not access the vmemmap and direct mapping areas before thesync.# The solution: Make page table sync more code robust and harder to missTo address this, Dave Hansen suggested [3] [4] introducing{pgd,p4d}_populate_kernel() for updating kernel portion of the page tablesand allow each architecture to explicitly perform synchronization wheninstalling top-level entries. With this approach, we no longer need toworry about missing the sync step, reducing the risk of futureregressions.The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK,PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used byvmalloc and ioremap to synchronize page tables.pgd_populate_kernel() looks like this:static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd, p4d_t *p4d){ pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr);}It is worth noting that vmalloc() and apply_to_range() carefullysynchronizes page tables by calling p*d_alloc_track() andarch_sync_kernel_mappings(), and thus they are not affected by---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ppp: fix memory leak in pad_compress_skbIf alloc_skb() fails in pad_compress_skb(), it returns NULL withoutreleasing the old skb. The caller does: skb = pad_compress_skb(ppp, skb); if (!skb) goto drop;drop: kfree_skb(skb);When pad_compress_skb() returns NULL, the reference to the old skb islost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.Align pad_compress_skb() semantics with realloc(): only free the oldskb if allocation and compression succeed. At the call site, use thenew_skb variable so the original skb is not lost when pad_compress_skb()fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: sme: cap SSID length in __cfg80211_connect_result()If the ssid->datalen is more than IEEE80211_MAX_SSID_LEN (32) it wouldlead to memory corruption so add some bounds checking.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objectsWhen the "proxy" option is enabled on a VXLAN device, the device willsuppress ARP requests and IPv6 Neighbor Solicitation messages if it isable to reply on behalf of the remote host. That is, if a matching andvalid neighbor entry is configured on the VXLAN device whose MAC addressis not behind the "any" remote (0.0.0.0 / ::).The code currently assumes that the FDB entry for the neighbor's MACaddress points to a valid remote destination, but this is incorrect ifthe entry is associated with an FDB nexthop group. This can result in aNPD [1][3] which can be reproduced using [2][4].Fix by checking that the remote destination exists before dereferencingit.[1]BUG: kernel NULL pointer dereference, address: 0000000000000000[...]CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014RIP: 0010:vxlan_xmit+0xb58/0x15f0[...]Call Trace: dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53[2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3[3]BUG: kernel NULL pointer dereference, address: 0000000000000000[...]CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014RIP: 0010:vxlan_xmit+0x803/0x1600[...]Call Trace: dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53RIP: 0033:0x7f383422ec77[4] #!/bin/bash ip address add 2001:db8:1::1/128 dev lo ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: Fix NPD when refreshing an FDB entry with a nexthop objectVXLAN FDB entries can point to either a remote destination or an FDBnexthop group. The latter is usually used in EVPN deployments wherelearning is disabled.However, when learning is enabled, an incoming packet might try torefresh an FDB entry that points to an FDB nexthop group and thereforedoes not have a remote. Such packets should be dropped, but they areonly dropped after dereferencing the non-existent remote, resulting in aNPD [1] which can be reproduced using [2].Fix by dropping such packets earlier. Remove the misleading comment fromfirst_remote_rcu().[1]BUG: kernel NULL pointer dereference, address: 0000000000000000[...]CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014RIP: 0010:vxlan_snoop+0x98/0x1e0[...]Call Trace: vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53[2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10 mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6When tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it justexits the function. This ends up causing a memory-leak:unreferenced object 0xffff0000281a8200 (size 2496): comm "softirq", pid 0, jiffies 4295174684 hex dump (first 32 bytes): 7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13 ................ 0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 ...a............ backtrace (crc 5ebdbe15): kmemleak_alloc+0x44/0xe0 kmem_cache_alloc_noprof+0x248/0x470 sk_prot_alloc+0x48/0x120 sk_clone_lock+0x38/0x3b0 inet_csk_clone_lock+0x34/0x150 tcp_create_openreq_child+0x3c/0x4a8 tcp_v6_syn_recv_sock+0x1c0/0x620 tcp_check_req+0x588/0x790 tcp_v6_rcv+0x5d0/0xc18 ip6_protocol_deliver_rcu+0x2d8/0x4c0 ip6_input_finish+0x74/0x148 ip6_input+0x50/0x118 ip6_sublist_rcv+0x2fc/0x3b0 ipv6_list_rcv+0x114/0x170 __netif_receive_skb_list_core+0x16c/0x200 netif_receive_skb_list_internal+0x1f0/0x2d0This is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), whenexiting upon error, inet_csk_prepare_forced_close() and tcp_done() needto be called. They make sure the newsk will end up being correctlyfree'd.tcp_v4_syn_recv_sock() makes this very clear by having the put_and_exitlabel that takes care of things. So, this patch here makes suretcp_v4_syn_recv_sock and tcp_v6_syn_recv_sock have similarerror-handling and thus fixes the leak for TCP-AO.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix potential invalid access when MAC list is emptylist_first_entry() never returns NULL - if the list is empty, it stillreturns a pointer to an invalid object, leading to potential invalidmemory access when dereferenced.Fix this by using list_first_entry_or_null instead of list_first_entry.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix one NULL pointer dereference in smc_ib_is_sg_need_sync()BUG: kernel NULL pointer dereference, address: 00000000000002ecPGD 0 P4D 0Oops: Oops: 0000 [#1] SMP PTICPU: 28 UID: 0 PID: 343 Comm: kworker/28:1 Kdump: loaded Tainted: G OE 6.17.0-rc2+ #9 NONETainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULEHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014Workqueue: smc_hs_wq smc_listen_work [smc]RIP: 0010:smc_ib_is_sg_need_sync+0x9e/0xd0 [smc]...Call Trace: smcr_buf_map_link+0x211/0x2a0 [smc] __smc_buf_create+0x522/0x970 [smc] smc_buf_create+0x3a/0x110 [smc] smc_find_rdma_v2_device_serv+0x18f/0x240 [smc] ? smc_vlan_by_tcpsk+0x7e/0xe0 [smc] smc_listen_find_device+0x1dd/0x2b0 [smc] smc_listen_work+0x30f/0x580 [smc] process_one_work+0x18c/0x340 worker_thread+0x242/0x360 kthread+0xe7/0x220 ret_from_fork+0x13a/0x160 ret_from_fork_asm+0x1a/0x30 If the software RoCE device is used, ibdev->dma_device is a null pointer.As a result, the problem occurs. Null pointer detection is added toprevent problems.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: ocp: fix use-after-free bugs causing by ptp_ocp_watchdogThe ptp_ocp_detach() only shuts down the watchdog timer if it ispending. However, if the timer handler is already running, thetimer_delete_sync() is not called. This leads to race conditionswhere the devlink that contains the ptp_ocp is deallocated whilethe timer handler is still accessing it, resulting in use-after-freebugs. The following details one of the race scenarios.(thread 1) | (thread 2)ptp_ocp_remove() | ptp_ocp_detach() | ptp_ocp_watchdog() if (timer_pending(&bp->watchdog))| bp = timer_container_of() timer_delete_sync() | | devlink_free(devlink) //free | | bp-> //useResolve this by unconditionally calling timer_delete_sync() to ensurethe timer is reliably deactivated, preventing any access after free.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info workThe brcmf_btcoex_detach() only shuts down the btcoex timer, if theflag timer_on is false. However, the brcmf_btcoex_timerfunc(), whichruns as timer handler, sets timer_on to false. This creates criticalrace conditions:1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc()is executing, it may observe timer_on as false and skip the call totimer_shutdown_sync().2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_infoworker after the cancel_work_sync() has been executed, resulting inuse-after-free bugs.The use-after-free bugs occur in two distinct scenarios, depending onthe timing of when the brcmf_btcoex_info struct is freed relative tothe execution of its worker thread.Scenario 1: Freed before the worker is scheduledThe brcmf_btcoex_info is deallocated before the worker is scheduled.A race condition can occur when schedule_work(&bt_local->work) iscalled after the target memory has been freed. The sequence of eventsis detailed below:CPU0 | CPU1brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USEScenario 2: Freed after the worker is scheduledThe brcmf_btcoex_info is freed after the worker has been scheduledbut before or during its execution. In this case, statements withinthe brcmf_btcoex_handler() - such as the container_of macro andsubsequent dereferences of the brcmf_btcoex_info object will causea use-after-free access. The following timeline illustrates thisscenario:CPU0 | CPU1brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker /* | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| */ |To resolve the race conditions, drop the conditional check and calltimer_shutdown_sync() directly. It can deactivate the timer reliably,regardless of its current state. Once stopped, the timer_on state isthen set to false.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: fix use-after-free in cmp_bss()Following bss_free() quirk introduced in commit 776b3580178f("cfg80211: track hidden SSID networks properly"), adjustcfg80211_update_known_bss() to free the last beacon frameelements only if they're not shared via the corresponding'hidden_beacon_bss' pointer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tee: fix NULL pointer dereference in tee_shm_puttee_shm_put have NULL pointer dereference:__optee_disable_shm_cache --> shm = reg_pair_to_ptr(...);//shm maybe return NULL tee_shm_free(shm); --> tee_shm_put(shm);//crashAdd check in tee_shm_put to fix it.panic log:Unable to handle kernel paging request at virtual address 0000000000100ccaMem abort info:ESR = 0x0000000096000004EC = 0x25: DABT (current EL), IL = 32 bitsSET = 0, FnV = 0EA = 0, S1PTW = 0FSC = 0x04: level 0 translation faultData abort info:ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000CM = 0, WnR = 0, TnD = 0, TagAccess = 0GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000[0000000000100cca] pgd=0000000000000000, p4d=0000000000000000Internal error: Oops: 0000000096000004 [#1] SMPCPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ----6.6.0-39-generic #38Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.010/26/2022pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : tee_shm_put+0x24/0x188lr : tee_shm_free+0x14/0x28sp : ffff001f98f9faf0x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffffx17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0cx8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100ccaCall trace:tee_shm_put+0x24/0x188tee_shm_free+0x14/0x28__optee_disable_shm_cache+0xa8/0x108optee_shutdown+0x28/0x38platform_shutdown+0x28/0x40device_shutdown+0x144/0x2b0kernel_power_off+0x3c/0x80hibernate+0x35c/0x388state_store+0x64/0x80kobj_attr_store+0x14/0x28sysfs_kf_write+0x48/0x60kernfs_fop_write_iter+0x128/0x1c0vfs_write+0x270/0x370ksys_write+0x6c/0x100__arm64_sys_write+0x20/0x30invoke_syscall+0x4c/0x120el0_svc_common.constprop.0+0x44/0xf0do_el0_svc+0x24/0x38el0_svc+0x24/0x88el0t_64_sync_handler+0x134/0x150el0t_64_sync+0x14c/0x15
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: xilinx_can: xcan_write_frame(): fix use-after-free of transmitted SKBcan_put_echo_skb() takes ownership of the SKB and it may be freedduring or after the call.However, xilinx_can xcan_write_frame() keeps using SKB after the call.Fix that by only calling can_put_echo_skb() after the code is donetouching the SKB.The tx_lock is held for the entire xcan_write_frame() execution andalso on the can_get_echo_skb() side so the order of operations does notmatter.An earlier fix commit 3d3c817c3a40 ("can: xilinx_can: Fix usage of skbmemory") did not move the can_put_echo_skb() call far enough.[mkl: add "commit" in front of sha1 in patch description][mkl: fix indention]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable()The function of_phy_find_device may return NULL, so we need to takecare before dereferencing phy_dev.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: fix invalid accesses to ceph_connection_v1_infoThere is a place where generic code in messenger.c is reading andanother place where it is writing to con->v1 union member withoutchecking that the union member is active (i.e. msgr1 is in use).On 64-bit systems, con->v1.auth_retry overlaps with con->v2.out_iter,so such a read is almost guaranteed to return a bogus value instead of0 when msgr2 is in use. This ends up being fairly benign because theside effect is just the invalidation of the authorizer and successivefetching of new tickets.con->v1.connect_seq overlaps with con->v2.conn_bufs and the fact thatit's being written to can cause more serious consequences, but luckilyit's not something that happens often.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kernfs: Fix UAF in polling when open file is releasedA use-after-free (UAF) vulnerability was identified in the PSI (PressureStall Information) monitoring mechanism:BUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140Read of size 8 at addr ffff3de3d50bd308 by task systemd/1psi_trigger_poll+0x3c/0x140cgroup_pressure_poll+0x70/0xa0cgroup_file_poll+0x8c/0x100kernfs_fop_poll+0x11c/0x1c0ep_item_poll.isra.0+0x188/0x2c0Allocated by task 1:cgroup_file_open+0x88/0x388kernfs_fop_open+0x73c/0xaf0do_dentry_open+0x5fc/0x1200vfs_open+0xa0/0x3f0do_open+0x7e8/0xd08path_openat+0x2fc/0x6b0do_filp_open+0x174/0x368Freed by task 8462:cgroup_file_release+0x130/0x1f8kernfs_drain_open_files+0x17c/0x440kernfs_drain+0x2dc/0x360kernfs_show+0x1b8/0x288cgroup_file_show+0x150/0x268cgroup_pressure_write+0x1dc/0x340cgroup_file_write+0x274/0x548Reproduction Steps:1. Open test/cpu.pressure and establish epoll monitoring2. Disable monitoring: echo 0 > test/cgroup.pressure3. Re-enable monitoring: echo 1 > test/cgroup.pressureThe race condition occurs because:1. When cgroup.pressure is disabled (echo 0 > cgroup.pressure), it: - Releases PSI triggers via cgroup_file_release() - Frees of->priv through kernfs_drain_open_files()2. While epoll still holds reference to the file and continues polling3. Re-enabling (echo 1 > cgroup.pressure) accesses freed of->privepolling disable/enable cgroup.pressurefd=open(cpu.pressure)while(1)...epoll_waitkernfs_fop_pollkernfs_get_active = true echo 0 > cgroup.pressure... cgroup_file_show kernfs_show // inactive kn kernfs_drain_open_files cft->release(of); kfree(ctx); ...kernfs_get_active = false echo 1 > cgroup.pressure kernfs_show kernfs_activate_one(kn);kernfs_fop_pollkernfs_get_active = truecgroup_file_pollpsi_trigger_poll// UAF...end: close(fd)To address this issue, introduce kernfs_get_active_of() for kernfs openfiles to obtain active references. This function will fail if the open filehas been released. Replace kernfs_get_active() with kernfs_get_active_of()to prevent further operations on released file descriptors.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memoryWhen I did memory failure tests, below panic occurs:page dumped because: VM_BUG_ON_PAGE(PagePoisoned(page))kernel BUG at include/linux/page-flags.h:616!Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTICPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40RIP: 0010:unpoison_memory+0x2f3/0x590RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffbR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffeFS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0Call Trace:
unpoison_memory+0x2f3/0x590 simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110 debugfs_attr_write+0x42/0x60 full_proxy_write+0x5b/0x80 vfs_write+0xd5/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f08f0314887RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffffR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00 Modules linked in: hwpoison_inject---[ end trace 0000000000000000 ]---RIP: 0010:unpoison_memory+0x2f3/0x590RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffbR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffeFS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0Kernel panic - not syncing: Fatal exceptionKernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)---[ end Kernel panic - not syncing: Fatal exception ]---The root cause is that unpoison_memory() tries to check the PG_HWPoisonflags of an uninitialized page. So VM_BUG_ON_PAGE(PagePoisoned(page)) istriggered. This can be reproduced by below steps:1.Offline memory block: echo offline > /sys/devices/system/memory/memory12/state2.Get offlined memory pfn: page-types -b n -rlN3.Write pfn to unpoison-pfn echo
> /sys/kernel/debug/hwpoison/unpoison-pfnThis scenario can be identified by pfn_to_online_page() returning NULL. And ZONE_DEVICE pages are never expected, so we can simply fail ifpfn_to_online_page() == NULL to fix the bug.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix subvolume deletion lockup caused by inodes xarray raceThere is a race condition between inode eviction and inode caching thatcan cause a live struct btrfs_inode to be missing from the root->inodesxarray. Specifically, there is a window during evict() between the inodebeing unhashed and deleted from the xarray. If btrfs_iget() is calledfor the same inode in that window, it will be recreated and insertedinto the xarray, but then eviction will delete the new entry, leavingnothing in the xarray:Thread 1 Thread 2---------------------------------------------------------------evict() remove_inode_hash() btrfs_iget_path() btrfs_iget_locked() btrfs_read_locked_inode() btrfs_add_inode_to_root() destroy_inode() btrfs_destroy_inode() btrfs_del_inode_from_root() __xa_eraseIn turn, this can cause issues for subvolume deletion. Specifically, ifan inode is in this lost state, and all other inodes are evicted, thenbtrfs_del_inode_from_root() will call btrfs_add_dead_root() prematurely.If the lost inode has a delayed_node attached to it, then whenbtrfs_clean_one_deleted_snapshot() calls btrfs_kill_all_delayed_nodes(),it will loop forever because the delayed_nodes xarray will never becomeempty (unless memory pressure forces the inode out). We saw thismanifest as soft lockups in production.Fix it by only deleting the xarray entry if it matches the given inode(using __xa_cmpxchg()).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix recursive semaphore deadlock in fiemap callsyzbot detected a OCFS2 hang due to a recursive semaphore on aFS_IOC_FIEMAP of the extent list on a specially crafted mmap file.context_switch kernel/sched/core.c:5357 [inline] __schedule+0x1798/0x4cc0 kernel/sched/core.c:6961 __schedule_loop kernel/sched/core.c:7043 [inline] schedule+0x165/0x360 kernel/sched/core.c:7058 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115 rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185 __down_write_common kernel/locking/rwsem.c:1317 [inline] __down_write kernel/locking/rwsem.c:1326 [inline] down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591 ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142 do_page_mkwrite+0x14d/0x310 mm/memory.c:3361 wp_page_shared mm/memory.c:3762 [inline] do_wp_page+0x268d/0x5800 mm/memory.c:3981 handle_pte_fault mm/memory.c:6068 [inline] __handle_mm_fault+0x1033/0x5440 mm/memory.c:6195 handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364 do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387 handle_page_fault arch/x86/mm/fault.c:1476 [inline] exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623RIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline]RIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline]RIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline]RIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 a4 0f1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41RSP: 0018:ffffc9000403f950 EFLAGS: 00050256RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060 copy_to_user include/linux/uaccess.h:225 [inline] fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145 ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806 ioctl_fiemap fs/ioctl.c:220 [inline] do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532 __do_sys_ioctl fs/ioctl.c:596 [inline] __se_sys_ioctl+0x82/0x170 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f5f13850fd9RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03bocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (sincev2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read theextent list of this running mmap executable. The user supplied buffer tohold the fiemap information page faults calling ocfs2_page_mkwrite() whichwill take a write lock (since v2.6.27-38-g00dc417fa3e7) of the samesemaphore. This recursive semaphore will hold filesystem locks and causesa hang of the fileystem.The ip_alloc_sem protects the inode extent list and size. Release theread semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap()and ocfs2_fiemap_inline(). This does an unnecessary semaphore lock/unlockon the last extent but simplifies the error path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() cancause various locking issues; see the following stack trace (edited forstyle) as one example:... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) double-acquiring the same [10.011575] kick_pool rq_lock, causing a hardlockup [10.011579] __queue_work [10.011582] queue_work_on [10.011585] kernfs_notify [10.011589] cgroup_file_notify [10.011593] try_charge_memcg (4) memcg accounting raises an [10.011597] obj_cgroup_charge_pages MEMCG_MAX event [10.011599] obj_cgroup_charge_account [10.011600] __memcg_slab_post_alloc_hook [10.011603] __kmalloc_node_noprof... [10.011611] bpf_map_kmalloc_node [10.011612] __bpf_async_init [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held [10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) grabs rq_lock...The above was reproduced on bpf-next (b338cf849ec8) by modifying./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() duringops.runnable(), and hacking the memcg accounting code a bit to makea bpf_timer_init() call more likely to raise an MEMCG_MAX event.We have also run into other similar variants (both internally and onbpf-next), including double-acquiring cgroup_file_kn_lock, the sameworker_pool::lock, etc.As suggested by Shakeel, fix this by using __GFP_HIGH instead ofGFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg()raises an MEMCG_MAX event, we call __memcg_memory_event() with@allow_spinning=false and avoid calling cgroup_file_notify() there.Depends on mm patch"memcg: skip cgroup_file_notify if spinning is not allowed":https://lore.kernel.org/bpf/20250905201606.66198-1-shakeel.butt@linux.dev/v0 approach s/bpf_map_kmalloc_node/bpf_mem_alloc/https://lore.kernel.org/bpf/20250905061919.439648-1-yepeilin@google.com/v1 approach:https://lore.kernel.org/bpf/20250905234547.862249-1-yepeilin@google.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/slub: avoid accessing metadata when pointer is invalid in object_err()object_err() reports details of an object for further debugging, such asthe freelist pointer, redzone, etc. However, if the pointer is invalid,attempting to access object metadata can lead to a crash since it doesnot point to a valid object.One known path to the crash is when alloc_consistency_checks()determines the pointer to the allocated object is invalid because of afreelist corruption, and calls object_err() to report it. The debug codeshould report and handle the corruption gracefully and not crash in theprocess.In case the pointer is NULL or check_valid_pointer() returns false forthe pointer, only print the pointer value and skip accessing metadata.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error pathIf request_irq() in i40e_vsi_request_irq_msix() fails in an iterationlater than the first, the error path wants to free the IRQs requestedso far. However, it uses the wrong dev_id argument for free_irq(), soit does not free the IRQs correctly and instead triggers the warning: Trying to free already-free IRQ 173 WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0 Modules linked in: i40e(+) [...] CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: [...] RIP: 0010:__free_irq+0x192/0x2c0 [...] Call Trace: free_irq+0x32/0x70 i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e] i40e_vsi_request_irq+0x79/0x80 [i40e] i40e_vsi_open+0x21f/0x2f0 [i40e] i40e_open+0x63/0x130 [i40e] __dev_open+0xfc/0x210 __dev_change_flags+0x1fc/0x240 netif_change_flags+0x27/0x70 do_setlink.isra.0+0x341/0xc70 rtnl_newlink+0x468/0x860 rtnetlink_rcv_msg+0x375/0x450 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x288/0x3c0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x3a2/0x3d0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x82/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] ---[ end trace 0000000000000000 ]---Use the same dev_id for free_irq() as for request_irq().I tested this with inserting code to fail intentionally.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork.syzbot reported the splat below. [0]The repro does the following: 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes) 2. Attach the prog to a SOCKMAP 3. Add a socket to the SOCKMAP 4. Activate fault injection 5. Send data less than cork_bytesAt 5., the data is carried over to the next sendmsg() as it issmaller than the cork_bytes specified by bpf_msg_cork_bytes().Then, tcp_bpf_send_verdict() tries to allocate psock->cork to holdthe data, but this fails silently due to fault injection + __GFP_NOWARN.If the allocation fails, we need to revert the sk->sk_forward_allocchange done by sk_msg_alloc().Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocatepsock->cork.The "*copied" also needs to be updated such that a proper error canbe returned to the caller, sendmsg. It fails to allocate psock->cork.Nothing has been corked so far, so this patch simply sets "*copied"to 0.[0]:WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983Modules linked in:CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fcRSP: 0018:ffffc90000a08b48 EFLAGS: 00010246RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0Call Trace: __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: j1939: implement NETDEV_UNREGISTER notification handlersyzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2problem, for j1939 protocol did not have NETDEV_UNREGISTER notificationhandler for undoing changes made by j1939_sk_bind().Commit 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destructcallback") expects that a call to j1939_priv_put() can be unconditionallydelayed until j1939_sk_sock_destruct() is called. But we need to callj1939_priv_put() against an extra ref held by j1939_sk_bind() call(as a part of undoing changes made by j1939_sk_bind()) as soon asNETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct()is called via j1939_sk_release()). Otherwise, the extra ref on "structj1939_priv" held by j1939_sk_bind() call prevents "struct net_device" fromdropping the usage count to 1; making it impossible forunregister_netdevice() to continue.[mkl: remove space in front of label]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Set merge to zero early in af_alg_sendmsgIf an error causes af_alg_sendmsg to abort, ctx->merge may containa garbage value from the previous loop. This may then trigger acrash on the next entry into af_alg_sendmsg when it attempts to doa merge that can't be done.Fix this by setting ctx->merge to zero near the start of the loop.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: codec: sma1307: Fix memory corruption in sma1307_setting_loaded()The sma1307->set.header_size is how many integers are in the header(there are 8 of them) but instead of allocating space of 8 integerswe allocate 8 bytes. This leads to memory corruption when we copy datait on the next line: memcpy(sma1307->set.header, data, sma1307->set.header_size * sizeof(int));Also since we're immediately copying over the memory in ->set.header,there is no need to zero it in the allocator. Use devm_kmalloc_array()to allocate the memory instead.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointerSince commit 7d5e9737efda ("net: rfkill: gpio: get the name and type fromdevice property") rfkill_find_type() gets called with the possiblyuninitialized "const char *type_name;" local variable.On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752"acpi_device, the rfkill->type is set based on the ACPI acpi_device_id: rfkill->type = (unsigned)id->driver_data;and there is no "type" property so device_property_read_string() will failand leave type_name uninitialized, leading to a potential crash.rfkill_find_type() does accept a NULL pointer, fix the potential crashby initializing type_name to NULL.Note likely sofar this has not been caught because:1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device2. The stack happened to contain NULL where type_name is stored
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failedIf earlier opening of source graph fails (e.g. ADSP rejects due toincorrect audioreach topology), the graph is closed and"dai_data->graph[dai->id]" is assigned NULL. Preparing the DAI for sinkgraph continues though and next call to q6apm_lpass_dai_prepare()receives dai_data->graph[dai->id]=NULL leading to NULL pointerexception: qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22 Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8 ... Call trace: q6apm_graph_media_format_pcm+0x48/0x120 (P) q6apm_lpass_dai_prepare+0x110/0x1b4 snd_soc_pcm_dai_prepare+0x74/0x108 __soc_pcm_prepare+0x44/0x160 dpcm_be_dai_prepare+0x124/0x1c0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: Fix use-after-free bugs in otx2_sync_tstamp()The original code relies on cancel_delayed_work() in otx2_ptp_destroy(),which does not ensure that the delayed work item synctstamp_work has fullycompleted if it was already running. This leads to use-after-free scenarioswhere otx2_ptp is deallocated by otx2_ptp_destroy(), while synctstamp_workremains active and attempts to dereference otx2_ptp in otx2_sync_tstamp().Furthermore, the synctstamp_work is cyclic, the likelihood of triggeringthe bug is nonnegligible.A typical race condition is illustrated below:CPU 0 (cleanup) | CPU 1 (delayed work callback)otx2_remove() | otx2_ptp_destroy() | otx2_sync_tstamp() cancel_delayed_work() | kfree(ptp) | | ptp = container_of(...); //UAF | ptp-> //UAFThis is confirmed by a KASAN report:BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0Write of size 8 at addr ffff88800aa09a18 by task bash/136...Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ...Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 otx2_ptp_init+0xb1/0x860 otx2_probe+0x4eb/0xc30 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30Freed by task 136: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 otx2_ptp_destroy+0x38/0x80 otx2_remove+0x10d/0x4c0 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f...Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the delayed work item is properly canceled before the otx2_ptp isdeallocated.This bug was initially identified through static analysis. To reproduceand test it, I simulated the OcteonTX2 PCI device in QEMU and introducedartificial delays within the otx2_sync_tstamp() function to increase thelikelihood of triggering the bug.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tls: make sure to abort the stream if headers are bogusNormally we wait for the socket to buffer up the whole recordbefore we service it. If the socket has a tiny buffer, however,we read out the data sooner, to prevent connection stalls.Make sure that we abort the connection when we find out latethat the record is actually invalid. Retrying the parsing isfine in itself but since we copy some more data each timebefore we parse we can overflow the allocated skb space.Constructing a scenario in which we're under pressure withoutenough data in the socket to parse the length upfront is quitehard. syzbot figured out a way to do this by serving us the headerin small OOB sends, and then filling in the recvbuf with a largenormal send.Make sure that tls_rx_msg_size() aborts strp, if we reachan invalid record there's really no way to recover.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tun: Update napi->skb after XDP processThe syzbot report a UAF issue: BUG: KASAN: slab-use-after-free in skb_reset_mac_header include/linux/skbuff.h:3150 [inline] BUG: KASAN: slab-use-after-free in napi_frags_skb net/core/gro.c:723 [inline] BUG: KASAN: slab-use-after-free in napi_gro_frags+0x6e/0x1030 net/core/gro.c:758 Read of size 8 at addr ffff88802ef22c18 by task syz.0.17/6079 CPU: 0 UID: 0 PID: 6079 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 skb_reset_mac_header include/linux/skbuff.h:3150 [inline] napi_frags_skb net/core/gro.c:723 [inline] napi_gro_frags+0x6e/0x1030 net/core/gro.c:758 tun_get_user+0x28cb/0x3e20 drivers/net/tun.c:1920 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 6079: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:330 [inline] __kasan_mempool_unpoison_object+0xa0/0x170 mm/kasan/common.c:558 kasan_mempool_unpoison_object include/linux/kasan.h:388 [inline] napi_skb_cache_get+0x37b/0x6d0 net/core/skbuff.c:295 __alloc_skb+0x11e/0x2d0 net/core/skbuff.c:657 napi_alloc_skb+0x84/0x7d0 net/core/skbuff.c:811 napi_get_frags+0x69/0x140 net/core/gro.c:673 tun_napi_alloc_frags drivers/net/tun.c:1404 [inline] tun_get_user+0x77c/0x3e20 drivers/net/tun.c:1784 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 6079: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:243 [inline] __kasan_slab_free+0x5b/0x80 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2422 [inline] slab_free mm/slub.c:4695 [inline] kmem_cache_free+0x18f/0x400 mm/slub.c:4797 skb_pp_cow_data+0xdd8/0x13e0 net/core/skbuff.c:969 netif_skb_check_for_xdp net/core/dev.c:5390 [inline] netif_receive_generic_xdp net/core/dev.c:5431 [inline] do_xdp_generic+0x699/0x11a0 net/core/dev.c:5499 tun_get_user+0x2523/0x3e20 drivers/net/tun.c:1872 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fAfter commit e6d5dbdd20aa ("xdp: add multi-buff support for xdp running ingeneric mode"), the original skb may be freed in skb_pp_cow_data() whenXDP program was attached, which was allocated in tun_napi_alloc_frags().However, the napi->skb still point to the original skb, update it afterXDP process.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/mce: use is_copy_from_user() to determine copy-from-user contextPatch series "mm/hwpoison: Fix regressions in memory failure handling",v4.## 1. What am I trying to do:This patchset resolves two critical regressions related to memory failurehandling that have appeared in the upstream kernel since version 5.17, ascompared to 5.10 LTS. - copyin case: poison found in user page while kernel copying from user space - instr case: poison found while instruction fetching in user space## 2. What is the expected outcome and why- For copyin case:Kernel can recover from poison found where kernel is doing get_user() orcopy_from_user() if those places get an error return and the kernel return-EFAULT to the process instead of crashing. More specifily, MCE handlerchecks the fixup handler type to decide whether an in kernel #MC can berecovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery codespecified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.- For instr case:If a poison found while instruction fetching in user space, full recoveryis possible. User process takes #PF, Linux allocates a new page and fillsby reading from storage.## 3. What actually happens and why- For copyin case: kernel panic since v5.17Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a newextable fixup type, EX_TYPE_EFAULT_REG, and later patches updated theextable fixup type for copy-from-user operations, changing it fromEX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESShandling when posion found in get_user() or copy_from_user().- For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE raceWhen an uncorrected memory error is consumed there is a race between theCMCI from the memory controller reporting an uncorrected error with a UCNAsignature, and the core reporting and SRAR signature machine check whenthe data is about to be consumed.### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]Prior to Icelake memory controllers reported patrol scrub events thatdetected a previously unseen uncorrected error in memory by signaling abroadcast machine check with an SRAO (Software Recoverable ActionOptional) signature in the machine check bank. This was overkill becauseit's not an urgent problem that no core is on the verge of consuming thatbad data. It's also found that multi SRAO UCE may cause nested MCEinterrupts and finally become an IERR.Hence, Intel downgrades the machine check bank signature of patrol scrubfrom SRAO to UCNA (Uncorrected, No Action required), and signal changed to#CMCI. Just to add to the confusion, Linux does take an action (inuc_decode_notifier()) to try to offline the page despite the UC*NA*signature name.### Background: why #CMCI and #MCE race when poison is consuming in Intel platform [1]Having decided that CMCI/UCNA is the best action for patrol scrub errors,the memory controller uses it for reads too. But the memory controller isexecuting asynchronously from the core, and can't tell the differencebetween a "real" read and a speculative read. So it will do CMCI/UCNA ifan error is found in any read.Thus:1) Core is clever and thinks address A is needed soon, issues a speculative read.2) Core finds it is going to use address A soon after sending the read request3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A.Quite often (because speculation has got better) the CMCI from the memorycontroller is delivered before the core is committed to the instructionreading address A, so the interrupt is taken, and Linux offlines the page(marking it as poison).## Why user process is killed for instr caseCommit 046545a661af ("mm/hwpoison: fix error page recovered but reported"not---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check the helper function is valid in get_helper_protokernel test robot reported verifier bug [1] where the helper funcpointer could be NULL due to disabled config option.As Alexei suggested we could check on that in get_helper_protodirectly. Marking tail_call helper func with BPF_PTR_POISON,because it is unused by design. [1] https://lore.kernel.org/oe-lkp/202507160818.68358831-lkp@intel.com
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: swap: check for stable address space before operating on the VMAIt is possible to hit a zero entry while traversing the vmas in unuse_mm()called from swapoff path and accessing it causes the OOPS:Unable to handle kernel NULL pointer dereference at virtual address0000000000000446--> Loading the memory from offset 0x40 on theXA_ZERO_ENTRY as address.Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation faultThe issue is manifested from the below race between the fork() on aprocess and swapoff:fork(dup_mmap()) swapoff(unuse_mm)--------------- -----------------1) Identical mtree is built using __mt_dup().2) copy_pte_range()--> copy_nonpresent_pte(): The dst mm is added into the mmlist to be visible to the swapoff operation.3) Fatal signal is sent to the parentprocess(which is the current during thefork) thus skip the duplication of thevmas and mark the vma range withXA_ZERO_ENTRY as a marker for this processthat helps during exit_mmap(). 4) swapoff is tried on the 'mm' added to the 'mmlist' as part of the 2. 5) unuse_mm(), that iterates through the vma's of this 'mm' will hit the non-NULL zero entry and operating on this zero entry as a vma is resulting into the oops.The proper fix would be around not exposing this partially-valid tree toothers when droping the mmap lock, which is being solved with [1]. Asimpler solution would be checking for MMF_UNSTABLE, as it is set ifmm_struct is not fully initialized in dup_mmap().Thanks to Liam/Lorenzo/David for all the suggestions in fixing thisissue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait()There is a bug observed when rtw89_core_tx_kick_off_and_wait() tries toaccess already freed skb_data: BUG: KFENCE: use-after-free write in rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 CPU: 6 UID: 0 PID: 41377 Comm: kworker/u64:24 Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025 Workqueue: events_unbound cfg80211_wiphy_work [cfg80211] Use-after-free write at 0x0000000020309d9d (in kfence-#251): rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.h:141 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 kfence-#251: 0x0000000056e2393d-0x000000009943cb62, size=232, cache=skbuff_head_cache allocated by task 41377 on cpu 6 at 77869.159548s (0.009551s ago): __alloc_skb net/core/skbuff.c:659 __netdev_alloc_skb net/core/skbuff.c:734 ieee80211_nullfunc_get net/mac80211/tx.c:5844 rtw89_core_send_nullfunc drivers/net/wireless/realtek/rtw89/core.c:3431 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.c:3194 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 freed by task 1045 on cpu 9 at 77869.168393s (0.001557s ago): ieee80211_tx_status_skb net/mac80211/status.c:1117 rtw89_pci_release_txwd_skb drivers/net/wireless/realtek/rtw89/pci.c:564 rtw89_pci_release_tx_skbs.isra.0 drivers/net/wireless/realtek/rtw89/pci.c:651 rtw89_pci_release_tx drivers/net/wireless/realtek/rtw89/pci.c:676 rtw89_pci_napi_poll drivers/net/wireless/realtek/rtw89/pci.c:4238 __napi_poll net/core/dev.c:7495 net_rx_action net/core/dev.c:7557 net/core/dev.c:7684 handle_softirqs kernel/softirq.c:580 do_softirq.part.0 kernel/softirq.c:480 __local_bh_enable_ip kernel/softirq.c:407 rtw89_pci_interrupt_threadfn drivers/net/wireless/realtek/rtw89/pci.c:927 irq_thread_fn kernel/irq/manage.c:1133 irq_thread kernel/irq/manage.c:1257 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258It is a consequence of a race between the waiting and the signaling sideof the completion: Waiting thread Completing threadrtw89_core_tx_kick_off_and_wait() rcu_assign_pointer(skb_data->wait, wait) /* start waiting */ wait_for_completion_timeout() rtw89_pci_tx_status() rtw89_core_tx_wait_complete() rcu_read_lock() /* signals completion and ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:afs: Fix potential null pointer dereference in afs_put_serverafs_put_server() accessed server->debug_id before the NULL check, whichcould lead to a null pointer dereference. Move the debug_id assignment,ensuring we never dereference a NULL server pointer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/gma500: Fix null dereference in hdmi teardownpci_set_drvdata sets the value of pdev->driver_data to NULL,after which the driver_data obtained from the same dev isdereferenced in oaktrail_hdmi_i2c_exit, and the i2c_dev isextracted from it. To prevent this, swap these calls.Found by Linux Verification Center (linuxtesting.org) with Svacer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc: Check return value of platform_get_resource()platform_get_resource() returns NULL in case of failure, so check itsreturn value and propagate the error in order to prevent NULL pointerdereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: check the return value of pinmux_ops::get_function_name()While the API contract in docs doesn't specify it explicitly, thegeneric implementation of the get_function_name() callback from structpinmux_ops - pinmux_generic_get_function_name() - can fail and returnNULL. This is already checked in pinmux_check_ops() so add a similarcheck in pinmux_func_name_to_selector() instead of passing the returnedpointer right down to strcmp() where the NULL can get dereferenced. Thisis normal operation when adding new pinfunctions.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leakStruct ff_effect_compat is embedded twice insideuinput_ff_upload_compat, contains internal padding. In particular, thereis a hole after struct ff_replay to satisfy alignment requirements forthe following union member. Without clearing the structure,copy_to_user() may leak stack data to userspace.Initialize ff_up_compat to zero before filling valid fields.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix race condition in kprobe initialization causing NULL pointer dereferenceThere is a critical race condition in kprobe initialization that can lead toNULL pointer dereference and kernel crash.[1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000...[1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO)[1135630.269239] pc : kprobe_perf_func+0x30/0x260[1135630.277643] lr : kprobe_dispatcher+0x44/0x60[1135630.286041] sp : ffffaeff4977fa40[1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400[1135630.302837] x27: 0000000000000000 x26: 0000000000000000[1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528[1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50[1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50[1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000[1135630.349985] x17: 0000000000000000 x16: 0000000000000000[1135630.359285] x15: 0000000000000000 x14: 0000000000000000[1135630.368445] x13: 0000000000000000 x12: 0000000000000000[1135630.377473] x11: 0000000000000000 x10: 0000000000000000[1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000[1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000[1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000[1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006[1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000[1135630.429410] Call trace:[1135630.434828] kprobe_perf_func+0x30/0x260[1135630.441661] kprobe_dispatcher+0x44/0x60[1135630.448396] aggr_pre_handler+0x70/0xc8[1135630.454959] kprobe_breakpoint_handler+0x140/0x1e0[1135630.462435] brk_handler+0xbc/0xd8[1135630.468437] do_debug_exception+0x84/0x138[1135630.475074] el1_dbg+0x18/0x8c[1135630.480582] security_file_permission+0x0/0xd0[1135630.487426] vfs_write+0x70/0x1c0[1135630.493059] ksys_write+0x5c/0xc8[1135630.498638] __arm64_sys_write+0x24/0x30[1135630.504821] el0_svc_common+0x78/0x130[1135630.510838] el0_svc_handler+0x38/0x78[1135630.516834] el0_svc+0x8/0x1b0kernel/trace/trace_kprobe.c: 13080xffff3df8995039ec : ldr x21, [x24,#120]include/linux/compiler.h: 2940xffff3df8995039f0 : ldr x1, [x21,x0]kernel/trace/trace_kprobe.c1308: head = this_cpu_ptr(call->perf_events);1309: if (hlist_empty(head))1310: return 0;crash> struct trace_event_call -ostruct trace_event_call { ... [120] struct hlist_head *perf_events; //(call->perf_event) ...}crash> struct trace_event_call ffffaf015340e528struct trace_event_call { ... perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0 ...}Race Condition Analysis:The race occurs between kprobe activation and perf_events initialization: CPU0 CPU1 ==== ==== perf_kprobe_init perf_trace_event_init tp_event->perf_events = list;(1) tp_event->class->reg (2)<- KPROBE ACTIVE Debug exception triggers ... kprobe_dispatcher kprobe_perf_func (tk->tp.flags & TP_FLAG_PROFILE) head = this_cpu_ptr(call->perf_events)(3) (perf_events is still NULL)Problem:1. CPU0 executes (1) assigning tp_event->perf_events = list2. CPU0 executes (2) enabling kprobe functionality via class->reg()3. CPU1 triggers and reaches kprobe_dispatcher4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed)5. CPU1 calls kprobe_perf_func() and crashes at (3) because call->perf_events is still NULLCPU1 sees that kprobe functionality is enabled but does not see thatperf_events has been assigned.Add pairing read an---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vhost: vringh: Modify the return value checkThe return value of copy_from_iter and copy_to_iter can't be negative,check whether the copied lengths are equal.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix crypto buffers in non-linear memoryThe crypto API, through the scatterlist API, expects input buffers to bein linear memory. We handle this with the cifs_sg_set_buf() helperthat converts vmalloc'd memory to their corresponding pages.However, when we allocate our aead_request buffer (@creq insmb2ops.c::crypt_message()), we do so with kvzalloc(), which possiblyputs aead_request->__ctx in vmalloc area.AEAD algorithm then uses ->__ctx for its private/internal data andoperations, and uses sg_set_buf() for such data on a few places.This works fine as long as @creq falls into kmalloc zone (smallrequests) or vmalloc'd memory is still within linear range.Tasks' stacks are vmalloc'd by default (CONFIG_VMAP_STACK=y), so toomany tasks will increment the base stacks' addresses to a point wherevirt_addr_valid(buf) will fail (BUG() in sg_set_buf()) when thathappens.In practice: too many parallel reads and writes on an encrypted mountwill trigger this bug.To fix this, always alloc @creq with kmalloc() instead.Also drop the @sensitive_size variable/arguments sincekfree_sensitive() doesn't need it.Backtrace:[ 945.272081] ------------[ cut here ]------------[ 945.272774] kernel BUG at include/linux/scatterlist.h:209![ 945.273520] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI[ 945.274412] CPU: 7 UID: 0 PID: 56 Comm: kworker/u33:0 Kdump: loaded Not tainted 6.15.0-lku-11779-g8e9d6efccdd7-dirty #1 PREEMPT(voluntary)[ 945.275736] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014[ 945.276877] Workqueue: writeback wb_workfn (flush-cifs-2)[ 945.277457] RIP: 0010:crypto_gcm_init_common+0x1f9/0x220[ 945.278018] Code: b0 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 c7 c0 00 00 00 80 48 2b 05 5c 58 e5 00 e9 58 ff ff ff <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 48 c7 04 24 01 00 00 00 48 8b[ 945.279992] RSP: 0018:ffffc90000a27360 EFLAGS: 00010246[ 945.280578] RAX: 0000000000000000 RBX: ffffc90001d85060 RCX: 0000000000000030[ 945.281376] RDX: 0000000000080000 RSI: 0000000000000000 RDI: ffffc90081d85070[ 945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 0000000000000000[ 945.282898] R10: ffffc90001d85090 R11: 0000000000001000 R12: ffffc90001d85070[ 945.283656] R13: ffff888113522948 R14: ffffc90001d85060 R15: ffffc90001d85010[ 945.284407] FS: 0000000000000000(0000) GS:ffff8882e66cf000(0000) knlGS:0000000000000000[ 945.285262] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 945.285884] CR2: 00007fa7ffdd31f4 CR3: 000000010540d000 CR4: 0000000000350ef0[ 945.286683] Call Trace:[ 945.286952] [ 945.287184] ? crypt_message+0x33f/0xad0 [cifs][ 945.287719] crypto_gcm_encrypt+0x36/0xe0[ 945.288152] crypt_message+0x54a/0xad0 [cifs][ 945.288724] smb3_init_transform_rq+0x277/0x300 [cifs][ 945.289300] smb_send_rqst+0xa3/0x160 [cifs][ 945.289944] cifs_call_async+0x178/0x340 [cifs][ 945.290514] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs][ 945.291177] smb2_async_writev+0x3e3/0x670 [cifs][ 945.291759] ? find_held_lock+0x32/0x90[ 945.292212] ? netfs_advance_write+0xf2/0x310[ 945.292723] netfs_advance_write+0xf2/0x310[ 945.293210] netfs_write_folio+0x346/0xcc0[ 945.293689] ? __pfx__raw_spin_unlock_irq+0x10/0x10[ 945.294250] netfs_writepages+0x117/0x460[ 945.294724] do_writepages+0xbe/0x170[ 945.295152] ? find_held_lock+0x32/0x90[ 945.295600] ? kvm_sched_clock_read+0x11/0x20[ 945.296103] __writeback_single_inode+0x56/0x4b0[ 945.296643] writeback_sb_inodes+0x229/0x550[ 945.297140] __writeback_inodes_wb+0x4c/0xe0[ 945.297642] wb_writeback+0x2f1/0x3f0[ 945.298069] wb_workfn+0x300/0x490[ 945.298472] process_one_work+0x1fe/0x590[ 945.298949] worker_thread+0x1ce/0x3c0[ 945.299397] ? __pfx_worker_thread+0x10/0x10[ 945.299900] kthr---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dlink: handle copy_thresh allocation failureThe driver did not handle failure of `netdev_alloc_skb_ip_align()`.If the allocation failed, dereferencing `skb->protocol` could lead toa NULL pointer dereference.This patch tries to allocate `skb`. If the allocation fails, it fallsback to the normal path.Tested-on: D-Link DGE-550T Rev-A3
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix double free in user_cluster_connect()user_cluster_disconnect() frees "conn->cc_private" which is "lc" but thenthe error handling frees "lc" a second time. Set "lc" to NULL on thispath to avoid a double free.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Disallow dirty tracking if incoherent page walkDirty page tracking relies on the IOMMU atomically updating the dirty bitin the paging-structure entry. For this operation to succeed, the paging-structure memory must be coherent between the IOMMU and the CPU. Inanother word, if the iommu page walk is incoherent, dirty page trackingdoesn't work.The Intel VT-d specification, Section 3.10 "Snoop Behavior" states:"Remapping hardware encountering the need to atomically update A/EA/D bits in a paging-structure entry that is not snooped will result in a non- recoverable fault."To prevent an IOMMU from being incorrectly configured for dirty pagetracking when it is operating in an incoherent mode, mark SSADS assupported only when both ecap_slads and ecap_smpwc are supported.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:coresight: trbe: Return NULL pointer for allocation failuresWhen the TRBE driver fails to allocate a buffer, it currently returnsthe error code "-ENOMEM". However, the caller etm_setup_aux() onlychecks for a NULL pointer, so it misses the error. As a result, thedriver continues and eventually causes a kernel panic.Fix this by returning a NULL pointer from arm_trbe_alloc_buffer() onallocation failures. This allows that the callers can properly handlethe failure.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix race in do_task() when drainingWhen do_task() exhausts its iteration budget (!ret), it sets the stateto TASK_STATE_IDLE to reschedule, without a secondary check on thecurrent task->state. This can overwrite the TASK_STATE_DRAINING stateset by a concurrent call to rxe_cleanup_task() or rxe_disable_task().While state changes are protected by a spinlock, both rxe_cleanup_task()and rxe_disable_task() release the lock while waiting for the task tofinish draining in the while(!is_done(task)) loop. The race occurs ifdo_task() hits its iteration limit and acquires the lock in this window.The cleanup logic may then proceed while the task incorrectlyreschedules itself, leading to a potential use-after-free.This bug was introduced during the migration from tasklets to workqueues,where the special handling for the draining case was lost.Fix this by restoring the original pre-migration behavior. If the state isTASK_STATE_DRAINING when iterations are exhausted, set cont to 1 toforce a new loop iteration. This allows the task to finish its work, sothat a subsequent iteration can reach the switch statement and correctlytransition the state to TASK_STATE_DRAINED, stopping the task as intended.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: hisilicon/qm - set NULL to qm->debug.qm_diff_regsWhen the initialization of qm->debug.acc_diff_reg fails,the probe process does not exit. However, after qm->debug.qm_diff_regs isfreed, it is not set to NULL. This can lead to a double free when theremove process attempts to free it again. Therefore, qm->debug.qm_diff_regsshould be set to NULL after it is freed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smc: Fix use-after-free in __pnet_find_base_ndev().syzbot reported use-after-free of net_device in __pnet_find_base_ndev(),which was called during connect(). [0]smc_pnet_find_ism_resource() fetches sk_dst_get(sk)->dev and passesdown to pnet_find_base_ndev(), where RTNL is held. Then, UAF happenedat __pnet_find_base_ndev() when the dev is first used.This means dev had already been freed before acquiring RTNL inpnet_find_base_ndev().While dev is going away, dst->dev could be swapped with blackhole_netdev,and the dev's refcnt by dst will be released.We must hold dev's refcnt before calling smc_pnet_find_ism_resource().Also, smc_pnet_find_roce_resource() has the same problem.Let's use __sk_dst_get() and dst_dev_rcu() in the two functions.[0]:BUG: KASAN: use-after-free in __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926 pnet_find_base_ndev net/smc/smc_pnet.c:946 [inline] smc_pnet_find_ism_by_pnetid net/smc/smc_pnet.c:1103 [inline] smc_pnet_find_ism_resource+0xef/0x390 net/smc/smc_pnet.c:1154 smc_find_ism_device net/smc/af_smc.c:1030 [inline] smc_find_proposal_devices net/smc/af_smc.c:1115 [inline] __smc_connect+0x372/0x1890 net/smc/af_smc.c:1545 smc_connect+0x877/0xd90 net/smc/af_smc.c:1715 __sys_connect_file net/socket.c:2086 [inline] __sys_connect+0x313/0x440 net/socket.c:2105 __do_sys_connect net/socket.c:2111 [inline] __se_sys_connect net/socket.c:2108 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2108 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f47cbf8eba9Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000bRBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8 The buggy address belongs to the physical page:page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bacflags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as freedpage last allocated via order 2, migratetype Unmovable, gfp_mask 0x446dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, free_ts 380670750466 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851 prep_new_page mm/page_alloc.c:1859 [inline] get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416 ___kmalloc_large_node+0x5f/0x1b0 mm/slub.c:4317 __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:4348 __do_kmalloc_node mm/slub.c:4364 [inline] __kvmalloc_node---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pps: fix warning in pps_register_cdev when register device failSimilar to previous commit 2a934fdb01db ("media: v4l2-dev: fix errorhandling in __video_register_device()"), the release hook should be setbefore device_register(). Otherwise, when device_register() return errorand put_device() try to callback the release function, the below warningmay happen. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4760 at drivers/base/core.c:2567 device_release+0x1bd/0x240 drivers/base/core.c:2567 Modules linked in: CPU: 1 UID: 0 PID: 4760 Comm: syz.4.914 Not tainted 6.17.0-rc3+ #1 NONE RIP: 0010:device_release+0x1bd/0x240 drivers/base/core.c:2567 Call Trace: kobject_cleanup+0x136/0x410 lib/kobject.c:689 kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0xe9/0x130 lib/kobject.c:737 put_device+0x24/0x30 drivers/base/core.c:3797 pps_register_cdev+0x2da/0x370 drivers/pps/pps.c:402 pps_register_source+0x2f6/0x480 drivers/pps/kapi.c:108 pps_tty_open+0x190/0x310 drivers/pps/clients/pps-ldisc.c:57 tty_ldisc_open+0xa7/0x120 drivers/tty/tty_ldisc.c:432 tty_set_ldisc+0x333/0x780 drivers/tty/tty_ldisc.c:563 tiocsetd drivers/tty/tty_io.c:2429 [inline] tty_ioctl+0x5d1/0x1700 drivers/tty/tty_io.c:2728 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:598 [inline] __se_sys_ioctl fs/ioctl.c:584 [inline] __x64_sys_ioctl+0x194/0x210 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x5f/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e Before commit c79a39dc8d06 ("pps: Fix a use-after-free"),pps_register_cdev() call device_create() to create pps->dev, which willinit dev->release to device_create_release(). Now the comment is outdated,just remove it.Thanks for the reminder from Calvin Owens, 'kfree_pps' should be removedin pps_register_source() to avoid a double free in the failure case.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: Don't block input queue by waiting MSCCurrently gsm_queue() processes incoming frames and when openinga DLC channel it calls gsm_dlci_open() which calls gsm_modem_update().If basic mode is used it calls gsm_modem_upd_via_msc() and itcannot block the input queue by waiting the response to comeinto the same input queue.Instead allow sending Modem Status Command without waiting for remoteend to respond. Define a new function gsm_modem_send_initial_msc()for this purpose. As MSC is only valid for basic encoding, it doesnot do anything for advanced or when convergence layer type 2 is used.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: start using dst_dev_rcu()Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF.Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(),ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp_metrics: use dst_dev_net_rcu()Replace three dst_dev() with a lockdep enabled helper.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Explicitly check accesses to bpf_sock_addrSyzkaller found a kernel warning on the following sock_addr program: 0: r0 = 0 1: r2 = *(u32 *)(r1 +60) 2: exitwhich triggers: verifier bug: error during ctx access conversion (0)This is happening because offset 60 in bpf_sock_addr corresponds to animplicit padding of 4 bytes, right after msg_src_ip4. Access to thispadding isn't rejected in sock_addr_is_valid_access and it thus laterfails to convert the access.This patch fixes it by explicitly checking the various fields ofbpf_sock_addr in sock_addr_is_valid_access.I checked the other ctx structures and is_valid_access functions anddidn't find any other similar cases. Other cases of (properly handled)padding are covered in new tests in a subsequent patch.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: restrict sockets to TCP and UDPRecently, syzbot started to abuse NBD with all kinds of sockets.Commit cf1b2326b734 ("nbd: verify socket is supported during setup")made sure the socket supported a shutdown() method.Explicitely accept TCP and UNIX stream sockets.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf: arm_spe: Prevent overflow in PERF_IDX2OFF()Cast nr_pages to unsigned long to avoid overflow when handling largeAUX buffer sizes (>= 2 GiB).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: Fix null-deref in agg_dequeueTo prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c)when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the returnvalue before using it, similar to the existing approach in sch_hfsc.c.To avoid code duplication, the following changes are made:1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a staticinline function.2. Moved qdisc_peek_len from net/sched/sch_hfsc.c toinclude/net/pkt_sched.h so that sch_qfq can reuse it.3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Define a proc_layoutcommit for the FlexFiles layout typeAvoid a crash if a pNFS client should happen to send a LAYOUTCOMMIToperation on a FlexFiles layout.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: Fix missing pointer check in hda_component_manager_init functionThe __component_match_add function may assign the 'matchptr' pointerthe value ERR_PTR(-ENOMEM), which will subsequently be dereferenced.The call stack leading to the error looks like this:hda_component_manager_init|-> component_match_add |-> component_match_add_release |-> __component_match_add ( ... ,**matchptr, ... ) |-> *matchptr = ERR_PTR(-ENOMEM); // assign|-> component_master_add_with_match( ... match) |-> component_match_realloc(match, match->num); // dereferenceAdd IS_ERR() check to prevent the crash.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not assert we found block group item when creating free space treeCurrently, when building a free space tree at populate_free_space_tree(),if we are not using the block group tree feature, we always expect to findblock group items (either extent items or a block group item with key typeBTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree withbtrfs_search_slot_for_read(), so we assert that we found an item. Howeverthis expectation is wrong since we can have a new block group created inthe current transaction which is still empty and for which we still havenot added the block group's item to the extent tree, in which case we donot have any items in the extent tree associated to the block group.The insertion of a new block group's block group item in the extent treehappens at btrfs_create_pending_block_groups() when it calls the helperinsert_block_group_item(). This typically is done when a transactionhandle is released, committed or when running delayed refs (either aspart of a transaction commit or when serving tickets for space reservationif we are low on free space).So remove the assertion at populate_free_space_tree() even when the blockgroup tree feature is not enabled and update the comment to mention thiscase.Syzbot reported this with the following stack trace: BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1115! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115 Code: ff ff e8 d3 (...) RSP: 0018:ffffc9000430f780 EFLAGS: 00010246 RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94 R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001 R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000 FS: 00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0 Call Trace: btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364 btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062 btrfs_remount_rw fs/btrfs/super.c:1334 [inline] btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559 reconfigure_super+0x227/0x890 fs/super.c:1076 do_remount fs/namespace.c:3279 [inline] path_mount+0xd1a/0xfe0 fs/namespace.c:4027 do_mount fs/namespace.c:4048 [inline] __do_sys_mount fs/namespace.c:4236 [inline] __se_sys_mount+0x313/0x410 fs/namespace.c:4213 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f424e39066a Code: d8 64 89 02 (...) RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000 RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020 R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380 R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0 Modules linked in: ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: fix divide-by-zero in comedi_buf_munge()The comedi_buf_munge() function performs a modulo operation`async->munge_chan %= async->cmd.chanlist_len` without firstchecking if chanlist_len is zero. If a user program submits a command withchanlist_len set to zero, this causes a divide-by-zero error when the deviceprocesses data in the interrupt handler path.Add a check for zero chanlist_len at the beginning of thefunction, similar to the existing checks for !map andCMDF_RAWDATA flag. When chanlist_len is zero, updatemunge_count and return early, indicating the data washandled without munging.This prevents potential kernel panics from malformed user commands.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: rng - Ensure set_ent is always presentEnsure that set_ent is always set since only drbg provides it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpt3sas: Fix crash in transport port remove by using ioc_info()During mpt3sas_transport_port_remove(), messages were logged withdev_printk() against &mpt3sas_port->port->dev. At this point the SAStransport device may already be partially unregistered or freed, leadingto a crash when accessing its struct device.Using ioc_info(), which logs via the PCI device (ioc->pdev->dev),guaranteed to remain valid until driver removal.[83428.295776] Oops: general protection fault, probably for non-canonical address 0x6f702f323a33312d: 0000 [#1] SMP NOPTI[83428.295785] CPU: 145 UID: 0 PID: 113296 Comm: rmmod Kdump: loaded Tainted: G OE 6.16.0-rc1+ #1 PREEMPT(voluntary)[83428.295792] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE[83428.295795] Hardware name: Dell Inc. Precision 7875 Tower/, BIOS 89.1.67 02/23/2024[83428.295799] RIP: 0010:__dev_printk+0x1f/0x70[83428.295805] Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 d1 48 85 f6 74 52 4c 8b 46 50 4d 85 c0 74 1f 48 8b 46 68 48 85 c0 74 22 <48> 8b 08 0f b6 7f 01 48 c7 c2 db e8 42 ad 83 ef 30 e9 7b f8 ff ff[83428.295813] RSP: 0018:ff85aeafc3137bb0 EFLAGS: 00010206[83428.295817] RAX: 6f702f323a33312d RBX: ff4290ee81292860 RCX: 5000cca25103be32[83428.295820] RDX: ff85aeafc3137bb8 RSI: ff4290eeb1966c00 RDI: ffffffffc1560845[83428.295823] RBP: ff85aeafc3137c18 R08: 74726f702f303a33 R09: ff85aeafc3137bb8[83428.295826] R10: ff85aeafc3137b18 R11: ff4290f5bd60fe68 R12: ff4290ee81290000[83428.295830] R13: ff4290ee6e345de0 R14: ff4290ee81290000 R15: ff4290ee6e345e30[83428.295833] FS: 00007fd9472a6740(0000) GS:ff4290f5ce96b000(0000) knlGS:0000000000000000[83428.295837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[83428.295840] CR2: 00007f242b4db238 CR3: 00000002372b8006 CR4: 0000000000771ef0[83428.295844] PKRU: 55555554[83428.295846] Call Trace:[83428.295848] [83428.295850] _dev_printk+0x5c/0x80[83428.295857] ? srso_alias_return_thunk+0x5/0xfbef5[83428.295863] mpt3sas_transport_port_remove+0x1c7/0x420 [mpt3sas][83428.295882] _scsih_remove_device+0x21b/0x280 [mpt3sas][83428.295894] ? _scsih_expander_node_remove+0x108/0x140 [mpt3sas][83428.295906] ? srso_alias_return_thunk+0x5/0xfbef5[83428.295910] mpt3sas_device_remove_by_sas_address.part.0+0x8f/0x110 [mpt3sas][83428.295921] _scsih_expander_node_remove+0x129/0x140 [mpt3sas][83428.295933] _scsih_expander_node_remove+0x6a/0x140 [mpt3sas][83428.295944] scsih_remove+0x3f0/0x4a0 [mpt3sas][83428.295957] pci_device_remove+0x3b/0xb0[83428.295962] device_release_driver_internal+0x193/0x200[83428.295968] driver_detach+0x44/0x90[83428.295971] bus_remove_driver+0x69/0xf0[83428.295975] pci_unregister_driver+0x2a/0xb0[83428.295979] _mpt3sas_exit+0x1f/0x300 [mpt3sas][83428.295991] __do_sys_delete_module.constprop.0+0x174/0x310[83428.295997] ? srso_alias_return_thunk+0x5/0xfbef5[83428.296000] ? __x64_sys_getdents64+0x9a/0x110[83428.296005] ? srso_alias_return_thunk+0x5/0xfbef5[83428.296009] ? syscall_trace_enter+0xf6/0x1b0[83428.296014] do_syscall_64+0x7b/0x2c0[83428.296019] ? srso_alias_return_thunk+0x5/0xfbef5[83428.296023] entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: host: max3421-hcd: Fix error pointer dereference in probe cleanupThe kthread_run() function returns error pointers so themax3421_hcd->spi_thread pointer can be either error pointers or NULL.Check for both before dereferencing it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlockPrevent USB runtime PM (autosuspend) for AX88772* in bind.usbnet enables runtime PM (autosuspend) by default, so disabling it viathe usb_driver flag is ineffective. On AX88772B, autosuspend shows nomeasurable power saving with current driver (no link partner, adminup/down). The ~0.453 W -> ~0.248 W drop on v6.1 comes from phylib poweringthe PHY off on admin-down, not from USB autosuspend.The real hazard is that with runtime PM enabled, ndo_open() (under RTNL)may synchronously trigger autoresume (usb_autopm_get_interface()) intoasix_resume() while the USB PM lock is held. Resume paths then invokephylink/phylib and MDIO, which also expect RTNL, leading to possibledeadlocks or PM lock vs MDIO wake issues.To avoid this, keep the device runtime-PM active by taking a usagereference in ax88772_bind() and dropping it in unbind(). A non-zero PMusage count blocks runtime suspend regardless of userspace policy(.../power/control - pm_runtime_allow/forbid), making this approachrobust against sysfs overrides.Holding a runtime-PM usage ref does not affect system-wide suspend;system sleep/resume callbacks continue to run as before.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Enforce expected_attach_type for tailcall compatibilityYinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object.The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as theentry point for bpf_prog_test_run_xdp() and its expected_attach_type canneither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slotof a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAPto pass xdp_is_valid_access() validation. The program returns struct xdp_md'segress_ifindex, and the latter is only allowed to be accessed under mentionedexpected_attach_type. progB is then inserted into the tailcall which progAcalls.The underlying issue goes beyond XDP though. Another example are programsof type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as wellas sock_addr_func_proto() have different logic depending on the programs'expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAMEshould not be allowed doing a tailcall into a program which calls bpf_bind()out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT.In short, specifying expected_attach_type allows to open up additionalfunctionality or restrictions beyond what the basic bpf_prog_type enables.The use of tailcalls must not violate these constraints. Fix it by enforcingexpected_attach_type in __bpf_prog_map_compatible().Note that we only enforce this for tailcall maps, but not for BPF devmaps orcpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() andcpu_map_bpf_prog_run*() which set up a new environment / context and thereforethese situations are not prone to this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwrng: ks-sa - fix division by zero in ks_sa_rng_initFix division by zero in ks_sa_rng_init caused by missing clockpointer initialization. The clk_get_rate() call is performed onan uninitialized clk pointer, resulting in division by zero whencalculating delay values.Add clock initialization code before using the clock. drivers/char/hw_random/ks-sa-rng.c | 7 +++++++ 1 file changed, 7 insertions(+)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: detect invalid INLINE_DATA + EXTENTS flag combinationsyzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verityfile on a corrupted ext4 filesystem mounted without a journal.The issue is that the filesystem has an inode with both the INLINE_DATAand EXTENTS flags set: EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15: comm syz.0.17: corrupted extent tree: lblk 0 < prev 66Investigation revealed that the inode has both flags set: DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1This is an invalid combination since an inode should have either:- INLINE_DATA: data stored directly in the inode- EXTENTS: data stored in extent-mapped blocksHaving both flags causes ext4_has_inline_data() to return true, skippingextent tree validation in __ext4_iget(). The unvalidated out-of-orderextents then trigger a BUG_ON in ext4_es_cache_extent() due to integerunderflow when calculating hole sizes.Fix this by detecting this invalid flag combination early in ext4_iget()and rejecting the corrupted inode.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pwm: berlin: Fix wrong register in suspend/resumeThe 'enable' register should be BERLIN_PWM_EN rather thanBERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, therewill be cpu exception then kernel panic during suspend/resume.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()Unlike other strings in the ext4 superblock, we rely on tune2fs tomake sure s_mount_opts is NUL terminated. Hardenparse_apply_sb_mount_options() by treating s_mount_opts as a potential__nonstring.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: reject negative file sizes in squashfs_read_inode()Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs.This warning is ultimately caused because the underlying Squashfs filesystem returns a file with a negative file size.This commit checks for a negative file size and returns EINVAL.[phillip@squashfs.org.uk: only need to check 64 bit quantity]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: avoid potential out-of-bounds in btrfs_encode_fh()The function btrfs_encode_fh() does not properly account for the threecases it handles.Before writing to the file handle (fh), the function only returns to theuser BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) orBTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes).However, when a parent exists and the root ID of the parent and theinode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT(10 dwords, 40 bytes).If *max_len is not large enough, this write goes out of bounds becauseBTRFS_FID_SIZE_CONNECTABLE_ROOT is greater thanBTRFS_FID_SIZE_CONNECTABLE originally returned.This results in an 8-byte out-of-bounds write atfid->parent_root_objectid = parent_root_id.A previous attempt to fix this issue was made but was lost.https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/Although this issue does not seem to be easily triggerable, it is apotential memory corruption bug that should be fixed. This patchresolves the issue by ensuring the function returns the appropriate sizefor all three cases and validates that *max_len is large enough beforewriting any data.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:most: usb: Fix use-after-free in hdm_disconnecthdm_disconnect() calls most_deregister_interface(), which eventuallyunregisters the MOST interface device with device_unregister(iface->dev).If that drops the last reference, the device core may call release_mdev()immediately while hdm_disconnect() is still executing.The old code also freed several mdev-owned allocations inhdm_disconnect() and then performed additional put_device() calls.Depending on refcount order, this could lead to use-after-free ordouble-free when release_mdev() ran (or when unregister paths alsoperformed puts).Fix by moving the frees of mdev-owned allocations into release_mdev(),so they happen exactly once when the device is truly released, and bydropping the extra put_device() calls in hdm_disconnect() that areredundant after device_unregister() and most_deregister_interface().This addresses the KASAN slab-use-after-free reported by syzbot inhdm_disconnect(). See report and stack traces in the bug link below.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: avoid NULL dereference when chunk data buffer is missingchunk->skb pointer is dereferenced in the if-block where it's supposedto be NULL only.chunk->skb can only be NULL if chunk->head_skb is not. Check for frag_listinstead and do it just before replacing chunk->skb. We're sure thatotherwise chunk->skb is non-NULL because of outer if() condition.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Ignore signal/timeout on connect() if already establishedDuring connect(), acting on a signal/timeout by disconnecting an alreadyestablished socket leads to several issues:1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling.2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs.3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref.Do not disconnect socket on signal/timeout. Keep the logic for unconnectedsockets: they don't linger, can't be placed in a sockmap, are rejected bysendmsg().[1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/[2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/[3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:devlink: rate: Unset parent pointer in devl_rate_nodes_destroyThe function devl_rate_nodes_destroy is documented to "Unset parent forall rate objects". However, it was only calling the driver-specific`rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementingthe parent's refcount, without actually setting the`devlink_rate->parent` pointer to NULL.This leaves a dangling pointer in the `devlink_rate` struct, which causerefcount error in netdevsim[1] and mlx5[2]. In addition, this isinconsistent with the behavior of `devlink_nl_rate_parent_node_set`,where the parent pointer is correctly cleared.This patch fixes the issue by explicitly setting `devlink_rate->parent`to NULL after notifying the driver, thus fulfilling the function'sdocumented behavior for all rate objects.[1]repro steps:echo 1 > /sys/bus/netdevsim/new_devicedevlink dev eswitch set netdevsim/netdevsim1 mode switchdevecho 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfsdevlink port function rate add netdevsim/netdevsim1/test_nodedevlink port function rate set netdevsim/netdevsim1/128 parent test_nodeecho 1 > /sys/bus/netdevsim/del_devicedmesg:refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONEHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:refcount_warn_saturate+0x42/0xe0Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53[2]devlink dev eswitch set pci/0000:08:00.0 mode switchdevdevlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000devlink port function rate add pci/0000:08:00.0/group1devlink port function rate set pci/0000:08:00.0/32768 parent group1modprobe -r mlx5_ib mlx5_fwctl mlx5_coredmesg:refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONEHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:refcount_warn_saturate+0x42/0xe0Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterateover 'cqe->len_list[]' using only a zero-length terminator asthe stopping condition. If the terminator was missing ormalformed, the loop could run past the end of the fixed-size array.Add an explicit bound check using ARRAY_SIZE() in both loops to preventa potential out-of-bounds access.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/ctcm: Fix double-kfreeThe function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionallyfrom function 'ctcmpc_unpack_skb'. It frees passed mpcginfo.After that a call to function 'kfree' in function 'ctcmpc_unpack_skb'frees it again.Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'.Bug detected by the clang static analyzer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: remove never-working support for setting nsh fieldsThe validation of the set(nsh(...)) action is completely wrong.It runs through the nsh_key_put_from_nlattr() function that is thesame function that validates NSH keys for the flow match and thepush_nsh() action. However, the set(nsh(...)) has a very differentmemory layout. Nested attributes in there are doubled in size incase of the masked set(). That makes proper validation impossible.There is also confusion in the code between the 'masked' flag, thatsays that the nested attributes are doubled in size containing boththe value and the mask, and the 'is_mask' that says that the valuewe're parsing is the mask. This is causing kernel crash on trying towrite into mask part of the match with SW_FLOW_KEY_PUT() duringvalidation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe third issue with this process is that while trying to convertthe non-masked set into masked one, validate_set() copies and doublesthe size of the OVS_KEY_ATTR_NSH as if it didn't have any nestedattributes. It should be copying each nested attribute and doublingthem in size independently. And the process must be properly reversedduring the conversion back from masked to a non-masked variant duringthe flow dump.In the end, the only two outcomes of trying to use this action areeither validation failure or a kernel crash. And if somehow someonemanages to install a flow with such an action, it will most definitelynot do what it is supposed to, since all the keys and the masks aremixed up.Fixing all the issues is a complex task as it requires re-writingmost of the validation code.Given that and the fact that this functionality never worked sinceintroduction, let's just remove it altogether. It's better tore-introduce it later with a proper implementation instead of tryingto fix it in stable releases.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: sg: Do not sleep in atomic contextsg_finish_rem_req() calls blk_rq_unmap_user(). The latter function maysleep. Hence, call sg_finish_rem_req() with interrupts enabled insteadof disabled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()nvme_fc_delete_assocation() waits for pending I/O to complete beforereturning, and an error can cause ->ioerr_work to be queued aftercancel_work_sync() had been called. Move the call to cancel_work_sync() tobe after nvme_fc_delete_association() to ensure ->ioerr_work is not runningwhen the nvme_fc_ctrl object is freed. Otherwise the following can occur:[ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL[ 1135.917705] ------------[ cut here ]------------[ 1135.922336] kernel BUG at lib/list_debug.c:52![ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI[ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary)[ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025[ 1135.950969] Workqueue: 0x0 (nvme-wq)[ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f[ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b[ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046[ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000[ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0[ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08[ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100[ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0[ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000[ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0[ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400[ 1136.055910] PKRU: 55555554[ 1136.058623] Call Trace:[ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0[ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0[ 1136.071898] ? move_linked_works+0x4a/0xa0[ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.081744] ? __die_body.cold+0x8/0x12[ 1136.085584] ? die+0x2e/0x50[ 1136.088469] ? do_trap+0xca/0x110[ 1136.091789] ? do_error_trap+0x65/0x80[ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.101289] ? exc_invalid_op+0x50/0x70[ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20[ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.120806] move_linked_works+0x4a/0xa0[ 1136.124733] worker_thread+0x216/0x3a0[ 1136.128485] ? __pfx_worker_thread+0x10/0x10[ 1136.132758] kthread+0xfa/0x240[ 1136.135904] ? __pfx_kthread+0x10/0x10[ 1136.139657] ret_from_fork+0x31/0x50[ 1136.143236] ? __pfx_kthread+0x10/0x10[ 1136.146988] ret_from_fork_asm+0x1a/0x30[ 1136.150915]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: cros_ec_keyb - fix an invalid memory accessIf cros_ec_keyb_register_matrix() isn't called (due to`buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remainsNULL. An invalid memory access is observed in cros_ec_keyb_process()when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work()in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_threadIt's still unknown about why the kernel receives such malformed event,in any cases, the kernel shouldn't access `ckdev->idev` and friends ifthe driver doesn't intend to initialize them.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:be2net: pass wrb_params in case of OS2BMCbe_insert_vlan_in_pkt() is called with the wrb_params argument being NULLat be_send_pkt_to_bmc() call site. This may lead to dereferencing a NULLpointer when processing a workaround for specific packet, as commitbc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6packet") states.The correct way would be to pass the wrb_params from be_xmit().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix potential overflow of PCM transfer bufferThe PCM stream data in USB-audio driver is transferred over USB URBpacket buffers, and each packet size is determined dynamically. Thepacket sizes are limited by some factors such as wMaxPacketSize USBdescriptor. OTOH, in the current code, the actually used packet sizesare determined only by the rate and the PPS, which may be bigger thanthe size limit above. This results in a buffer overflow, as reportedby syzbot.Basically when the limit is smaller than the calculated packet size,it implies that something is wrong, most likely a weird USBdescriptor. So the best option would be just to return an error atthe parameter setup time before doing any further operations.This patch introduces such a sanity check, and returns -EINVAL whenthe packet size is greater than maxpacksize. The comparison withep->packsize[1] alone should suffice since it's always equal orgreater than ep->packsize[0].
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/secretmem: fix use-after-free race in fault handlerWhen a page fault occurs in a secret memory file created with`memfd_secret(2)`, the kernel will allocate a new folio for it, mark theunderlying page as not-present in the direct map, and add it to the filemapping.If two tasks cause a fault in the same page concurrently, both could endup allocating a folio and removing the page from the direct map, but onlyone would succeed in adding the folio to the file mapping. The task thatfailed undoes the effects of its attempt by (a) freeing the folio againand (b) putting the page back into the direct map. However, by doingthese two operations in this order, the page becomes available to theallocator again before it is placed back in the direct mapping.If another task attempts to allocate the page between (a) and (b), and thekernel tries to access it via the direct map, it would result in asupervisor not-present page fault.Fix the ordering to restore the direct map before the folio is freed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: free copynotify stateid in nfs4_free_ol_stateid()Typically copynotify stateid is freed either when parent's stateidis being close/freed or in nfsd4_laundromat if the stateid hasn'tbeen used in a lease period.However, in case when the server got an OPEN (which createda parent stateid), followed by a COPY_NOTIFY using that stateid,followed by a client reboot. New client instance while doingCREATE_SESSION would force expire previous state of this client.It leads to the open state being freed thru release_openowner->nfs4_free_ol_stateid() and it finds that it still has copynotifystateid associated with it. We currently print a warning and istriggerredWARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd]This patch, instead, frees the associated copynotify stateid here.If the parent stateid is freed (without freeing the copynotifystateids associated with it), it leads to the list corruptionwhen laundromat ends up freeing the copynotify state later.[ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP[ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink[ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary)[ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN[ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024[ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd][ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)[ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200[ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200[ 1626.861182] sp : ffff8000881d7a40[ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200[ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20[ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8[ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000[ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065[ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3[ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000[ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001[ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000[ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d[ 1626.868167] Call trace:[ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P)[ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd][ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd][ 1626.869813] laundromat_main+0x24/0x60 [nfsd][ 1626.870231] process_one_work+0x584/0x1050[ 1626.870595] worker_thread+0x4c4/0xc60[ 1626.870893] kthread+0x2f8/0x398[ 1626.871146] ret_from_fork+0x10/0x20[ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000)[ 1626.871892] SMP: stopping secondary CPUs
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix NULL pointer dereference in snd_usb_mixer_controls_baddIn snd_usb_create_streams(), for UAC version 3 devices, the InterfaceAssociation Descriptor (IAD) is retrieved via usb_ifnum_to_if(). If thiscall fails, a fallback routine attempts to obtain the IAD from the nextinterface and sets a BADD profile. However, snd_usb_mixer_controls_badd()assumes that the IAD retrieved from usb_ifnum_to_if() is always valid,without performing a NULL check. This can lead to a NULL pointerdereference when usb_ifnum_to_if() fails to find the interface descriptor.This patch adds a NULL pointer check after calling usb_ifnum_to_if() insnd_usb_mixer_controls_badd() to prevent the dereference.This issue was discovered by syzkaller, which triggered the bug by sendinga crafted USB device descriptor.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleakFix a KMSAN kernel-infoleak detected by the syzbot .[net?] KMSAN: kernel-infoleak in __skb_datagram_iterIn tcf_ife_dump(), the variable 'opt' was partially initialized using adesignatied initializer. While the padding bytes are reamineduninitialized. nla_put() copies the entire structure into anetlink message, these uninitialized bytes leaked to userspace.Initialize the structure with memset before assigning its fieldsto ensure all members and padding are cleared prior to beign copied.This change silences the KMSAN report and prevents potential informationleaks from the kernel memory.This fix has been tested and validated by syzbot. This patch closes thebug reported at the following syzkaller link and ensures no infoleak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix improper check of dentry.stream.valid_sizeWe found an infinite loop bug in the exFAT file system that can lead to aDenial-of-Service (DoS) condition. When a dentry in an exFAT filesystem ismalformed, the following system calls - SYS_openat, SYS_ftruncate, andSYS_pwrite64 - can cause the kernel to hang.Root cause analysis shows that the size validation code in exfat_find()does not check whether dentry.stream.valid_size is negative. As a result,the system calls mentioned above can succeed and eventually trigger the DoSissue.This patch adds a check for negative dentry.stream.valid_size to preventthis vulnerability.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devicesPreviously, APU platforms (and other scenarios with uninitialized VRAM managers)triggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The rootcause is not that the `struct ttm_resource_manager *man` pointer itself is NULL,but that `man->bdev` (the backing device pointer within the manager) remainsuninitialized (NULL) on APUs-since APUs lack dedicated VRAM and do not fullyset up VRAM manager structures. When `ttm_resource_manager_usage()` attempts toacquire `man->bdev->lru_lock`, it dereferences the NULL `man->bdev`, leading toa kernel OOPS.1. **amdgpu_cs.c**: Extend the existing bandwidth control check in `amdgpu_cs_get_threshold_for_moves()` to include a check for `ttm_resource_manager_used()`. If the manager is not used (uninitialized `bdev`), return 0 for migration thresholds immediately-skipping VRAM-specific logic that would trigger the NULL dereference.2. **amdgpu_kms.c**: Update the `AMDGPU_INFO_VRAM_USAGE` ioctl and memory info reporting to use a conditional: if the manager is used, return the real VRAM usage; otherwise, return 0. This avoids accessing `man->bdev` when it is NULL.3. **amdgpu_virt.c**: Modify the vf2pf (virtual function to physical function) data write path. Use `ttm_resource_manager_used()` to check validity: if the manager is usable, calculate `fb_usage` from VRAM usage; otherwise, set `fb_usage` to 0 (APUs have no discrete framebuffer to report).This approach is more robust than APU-specific checks because it:- Works for all scenarios where the VRAM manager is uninitialized (not just APUs),- Aligns with TTM's design by using its native helper function,- Preserves correct behavior for discrete GPUs (which have fully initialized `man->bdev` and pass the `ttm_resource_manager_used()` check).v4: use ttm_resource_manager_used(&adev->mman.vram_mgr.manager) instead of checking the adev->gmc.is_app_apu flag (Christian)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-boundsAdd bounds checking to prevent writes past framebuffer boundaries whenrendering text near screen edges. Return early if the Y position is off-screenand clip image height to screen boundary. Break from the rendering loop if theX position is off-screen. When clipping image width to fit the screen, updatethe character count to match the clipped width to prevent buffer sizemismatches.Without the character count update, bit_putcs_aligned and bit_putcs_unalignedreceive mismatched parameters where the buffer is allocated for the clippedwidth but cnt reflects the original larger count, causing out-of-bounds writes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:exfat: validate cluster allocation bits of the allocation bitmapsyzbot created an exfat image with cluster bits not set for the allocationbitmap. exfat-fs reads and uses the allocation bitmap without checkingthis. The problem is that if the start cluster of the allocation bitmapis 6, cluster 6 can be allocated when creating a directory with mkdir.exfat zeros out this cluster in exfat_mkdir, which can delete existingentries. This can reallocate the allocated entries. In addition,the allocation bitmap is also zeroed out, so cluster 6 can be reallocated.This patch adds exfat_test_bitmap_range to validate that clusters used forthe allocation bitmap are correctly marked as in-use.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:amd/amdkfd: resolve a race in amdgpu_amdkfd_device_fini_swThere is race in amdgpu_amdkfd_device_fini_sw and interrupt.if amdgpu_amdkfd_device_fini_sw run in b/w kfd_cleanup_nodes and kfree(kfd), and KGD interrupt generated.kernel panic log:BUG: kernel NULL pointer dereference, address: 0000000000000098amdgpu 0000:c8:00.0: amdgpu: Requesting 4 partitions through PSPPGD d78c68067 P4D d78c68067kfd kfd: amdgpu: Allocated 3969056 bytes on gartPUD 1465b8067 PMD @Oops: @002 [#1] SMP NOPTIkfd kfd: amdgpu: Total number of KFD nodes to be created: 4CPU: 115 PID: @ Comm: swapper/115 Kdump: loaded Tainted: G S W OE KRIP: 0010:_raw_spin_lock_irqsave+0x12/0x40Code: 89 e@ 41 5c c3 cc cc cc cc 66 66 2e Of 1f 84 00 00 00 00 00 OF 1f 40 00 Of 1f 44% 00 00 41 54 9c 41 5c fa 31 cO ba 01 00 00 00 OF b1 17 75 Ba 4c 89 e@ 41 Sc89 c6 e8 07 38 5dRSP: 0018: ffffc90@1a6b0e28 EFLAGS: 00010046RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000000000180000000000000001 RSI: ffff8883bb623e00 RDI: 0000000000000098ffff8883bb000000 RO8: ffff888100055020 ROO: ffff8881000550200000000000000000 R11: 0000000000000000 R12: 0900000000000002ffff888F2b97da0@ R14: @000000000000098 R15: ffff8883babdfo00CS: 010 DS: 0000 ES: 0000 CRO: 0000000080050033CR2: 0000000000000098 CR3: 0000000e7cae2006 CR4: 0000000002770ce00000000000000000 DR1: 0000000000000000 DR2: 00000000000000000000000000000000 DR6: 00000000fffeO7FO DR7: 0000000000000400PKRU: 55555554Call Trace:kgd2kfd_interrupt+@x6b/0x1f@ [amdgpu]? amdgpu_fence_process+0xa4/0x150 [amdgpu]kfd kfd: amdgpu: Node: 0, interrupt_bitmap: 3 YcpxFl Rant tEraceamdgpu_irq_dispatch+0x165/0x210 [amdgpu]amdgpu_ih_process+0x80/0x100 [amdgpu]amdgpu: Virtual CRAT table created for GPUamdgpu_irq_handler+0x1f/@x60 [amdgpu]__handle_irq_event_percpu+0x3d/0x170amdgpu: Topology: Add dGPU node [0x74a2:0x1002]handle_irq_event+0x5a/@xcOhandle_edge_irq+0x93/0x240kfd kfd: amdgpu: KFD node 1 partition @ size 49148Masm_call_irq_on_stack+0xf/@x20common_interrupt+0xb3/0x130asm_common_interrupt+0x1le/0x405.10.134-010.a1i5000.a18.x86_64 #1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regmap: slimbus: fix bus_context pointer in regmap init callsCommit 4e65bda8273c ("ASoC: wcd934x: fix error handling inwcd934x_codec_parse_data()") revealed the problem in the slimbus regmap.That commit breaks audio playback, for instance, on sdm845 ThundercommDragonboard 845c board: Unable to handle kernel paging request at virtual address ffff8000847cbad4 ... CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT Hardware name: Thundercomm Dragonboard 845c (DT) ... Call trace: slim_xfer_msg+0x24/0x1ac [slimbus] (P) slim_read+0x48/0x74 [slimbus] regmap_slimbus_read+0x18/0x24 [regmap_slimbus] _regmap_raw_read+0xe8/0x174 _regmap_bus_read+0x44/0x80 _regmap_read+0x60/0xd8 _regmap_update_bits+0xf4/0x140 _regmap_select_page+0xa8/0x124 _regmap_raw_write_impl+0x3b8/0x65c _regmap_bus_raw_write+0x60/0x80 _regmap_write+0x58/0xc0 regmap_write+0x4c/0x80 wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x] snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core] __soc_pcm_hw_params+0x22c/0x634 [snd_soc_core] dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core] dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core] snd_pcm_hw_params+0x124/0x464 [snd_pcm] snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm] snd_pcm_ioctl+0x34/0x4c [snd_pcm] __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xec el0t_64_sync_handler+0xa0/0xf0 el0t_64_sync+0x198/0x19cThe __devm_regmap_init_slimbus() started to be used instead of__regmap_init_slimbus() after the commit mentioned above and turns outthe incorrect bus_context pointer (3rd argument) was used in__devm_regmap_init_slimbus(). It should be just "slimbus" (which is equalto &slimbus->dev). Correct it. The wcd934x codec seems to be the only orthe first user of devm_regmap_init_slimbus() but we should fix it tillthe point where __devm_regmap_init_slimbus() was introduced thereforetwo "Fixes" tags.While at this, also correct the same argument in __regmap_init_slimbus().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Sync pending IRQ work before freeing ring bufferFix a race where irq_work can be queued in bpf_ringbuf_commit()but the ring buffer is freed before the work executes.In the syzbot reproducer, a BPF program attached to sched_switchtriggers bpf_ringbuf_commit(), queuing an irq_work. If the ring bufferis freed before this work executes, the irq_work thread may accessesfreed memory.Calling `irq_work_sync(&rb->work)` ensures that all pending irq_workcomplete before freeing the buffer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix crash while sending Action Frames in standalone AP ModeCurrently, whenever there is a need to transmit an Action frame,the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR tofirmware. The P2P interfaces were available when wpa_supplicant is managingthe wlan interface.However, the P2P interfaces are not created/initialized when only hostapdis managing the wlan interface. And if hostapd receives an ANQP Query REQAction frame even from an un-associated STA, the brcmfmac driver triesto use an uninitialized P2P vif pointer for sending the IOVAR to firmware.This NULL pointer dereferencing triggers a driver crash. [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211] [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158 [ 1417.076302] genl_rcv_msg+0x220/0x2a0 [ 1417.076317] netlink_rcv_skb+0x68/0x140 [ 1417.076330] genl_rcv+0x40/0x60 [ 1417.076343] netlink_unicast+0x330/0x3b8 [ 1417.076357] netlink_sendmsg+0x19c/0x3f8 [ 1417.076370] __sock_sendmsg+0x64/0xc0 [ 1417.076391] ____sys_sendmsg+0x268/0x2a0 [ 1417.076408] ___sys_sendmsg+0xb8/0x118 [ 1417.076427] __sys_sendmsg+0x90/0xf8 [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40 [ 1417.076465] invoke_syscall+0x50/0x120 [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0 [ 1417.076506] do_el0_svc+0x24/0x38 [ 1417.076525] el0_svc+0x30/0x100 [ 1417.076548] el0t_64_sync_handler+0x100/0x130 [ 1417.076569] el0t_64_sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000)Fix this, by always using the vif corresponding to the wdev on which theAction frame Transmission request was initiated by the userspace. This way,even if P2P vif is not available, the IOVAR is sent to firmware on AP vifand the ANQP Query RESP Action frame is transmitted without crashing thedriver.Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev()to brcmf_p2p_attach(). Because the former function would not get executedwhen only hostapd is managing wlan interface, and it is not safe to doreinit_completion() later in brcmf_p2p_tx_action_frame(), without any priorinit_completion().And in the brcmf_p2p_tx_action_frame() function, the condition check forP2P Presence response frame is not needed, since the wpa_supplicant isproperly sending the P2P Presense Response frame on the P2P-GO vif insteadof the P2P-Device vif.[Cc stable]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Fix crash in nfsd4_read_release()When tracing is enabled, the trace_nfsd_read_done trace pointcrashes during the pynfs read.testNoFh test.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: wait barrier before returning discard request with REQ_NOWAITraid10_handle_discard should wait barrier before returning a discard biowhich has REQ_NOWAIT. And there is no need to print warning calltraceif a discard bio has REQ_NOWAIT flag. Quality engineer usually checksdmesg and reports error if dmesg has warning/error calltrace.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential UAF in smb2_close_cached_fid()find_or_create_cached_dir() could grab a new reference after kref_put()had seen the refcount drop to zero but before cfid_list_lock is acquiredin smb2_close_cached_fid(), leading to use-after-free.Switch to kref_put_lock() so cfid_release() is called withcfid_list_lock held, closing that gap.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: Correctly handle Rx checksum offload errorsThe stmmac_rx function would previously set skb->ip_summed toCHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabledand the packet was of a known IP ethertype.However, this logic failed to check if the hardware had actuallyreported a checksum error. The hardware status, indicating a header orpayload checksum failure, was being ignored at this stage. This couldcause corrupt packets to be passed up the network stack as valid.This patch corrects the logic by checking the `csum_none` status flag,which is set when the hardware reports a checksum error. If this flagis set, skb->ip_summed is now correctly set to CHECKSUM_NONE,ensuring the kernel's network stack will perform its own validation andproperly handle the corrupt packet.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:futex: Don't leak robust_list pointer on exec racesys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()to check if the calling task is allowed to access another task'srobust_list pointer. This check is racy against a concurrent exec() in thetarget process.During exec(), a task may transition from a non-privileged binary to aprivileged one (e.g., setuid binary) and its credentials/memory mappingsmay change. If get_robust_list() performs ptrace_may_access() beforethis transition, it may erroneously allow access to sensitive informationafter the target becomes privileged.A racy access allows an attacker to exploit a window during whichptrace_may_access() passes before a target process transitions to aprivileged state via exec().For example, consider a non-privileged task T that is about to execute asetuid-root binary. An attacker task A calls get_robust_list(T) while Tis still unprivileged. Since ptrace_may_access() checks permissionsbased on current credentials, it succeeds. However, if T begins execimmediately afterwards, it becomes privileged and may change its memorymappings. Because get_robust_list() proceeds to access T->robust_listwithout synchronizing with exec() it may read user-space pointers from anow-privileged process.This violates the intended post-exec access restrictions and couldexpose sensitive memory addresses or be used as a primitive in a largerexploit chain. Consequently, the race can lead to unauthorizeddisclosure of information across privilege boundaries and poses apotential security risk.Take a read lock on signal->exec_update_lock prior to invokingptrace_may_access() and accessing the robust_list/compat_robust_list.This ensures that the target task's exec state remains stable during thecheck, allowing for consistent and synchronized validation ofcredentials.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity()which causes the code to proceed with NULL clock pointers. The currentlogic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for bothvalid pointers and NULL, leading to potential NULL pointer dereferencein clk_get_rate().Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:"The error code within @ptr if it is an error pointer; 0 otherwise."This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULLpointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed)when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to becalled when of_clk_get() returns NULL.Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for validpointers, preventing potential NULL pointer dereference in clk_get_rate().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: fix the deadlock of enetc_mdio_lockAfter applying the workaround for err050089, the LS1028A platformexperiences RCU stalls on RT kernel. This issue is caused by therecursive acquisition of the read lock enetc_mdio_lock. Here list someof the call stacks identified under the enetc_poll path that may lead toa deadlock:enetc_poll -> enetc_lock_mdio -> enetc_clean_rx_ring OR napi_complete_done -> napi_gro_receive -> enetc_start_xmit -> enetc_lock_mdio -> enetc_map_tx_buffs -> enetc_unlock_mdio -> enetc_unlock_mdioAfter enetc_poll acquires the read lock, a higher-priority writer attemptsto acquire the lock, causing preemption. The writer detects that aread lock is already held and is scheduled out. However, readers underenetc_poll cannot acquire the read lock again because a writer is alreadywaiting, leading to a thread hang.Currently, the deadlock is avoided by adjusting enetc_lock_mdio to preventrecursive lock acquisition.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sysfs: check visibility before changing group attribute ownershipSince commit 0c17270f9b92 ("net: sysfs: Implement is_visible forphys_(port_id, port_name, switch_id)"), __dev_change_net_namespace() canhit WARN_ON() when trying to change owner of a file that isn't visible.See the trace below: WARNING: CPU: 6 PID: 2938 at net/core/dev.c:12410 __dev_change_net_namespace+0xb89/0xc30 CPU: 6 UID: 0 PID: 2938 Comm: incusd Not tainted 6.17.1-1-mainline #1 PREEMPT(full) 4b783b4a638669fb644857f484487d17cb45ed1f Hardware name: Framework Laptop 13 (AMD Ryzen 7040Series)/FRANMDCP07, BIOS 03.07 02/19/2025 RIP: 0010:__dev_change_net_namespace+0xb89/0xc30 [...] Call Trace: ? if6_seq_show+0x30/0x50 do_setlink.isra.0+0xc7/0x1270 ? __nla_validate_parse+0x5c/0xcc0 ? security_capable+0x94/0x1a0 rtnl_newlink+0x858/0xc20 ? update_curr+0x8e/0x1c0 ? update_entity_lag+0x71/0x80 ? sched_balance_newidle+0x358/0x450 ? psi_task_switch+0x113/0x2a0 ? __pfx_rtnl_newlink+0x10/0x10 rtnetlink_rcv_msg+0x346/0x3e0 ? sched_clock+0x10/0x30 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 netlink_rcv_skb+0x59/0x110 netlink_unicast+0x285/0x3c0 ? __alloc_skb+0xdb/0x1a0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x39f/0x3d0 ? import_iovec+0x2f/0x40 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x81/0x970 ? __sys_bind+0xe3/0x110 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? sock_alloc_file+0x63/0xc0 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? alloc_fd+0x12e/0x190 ? put_unused_fd+0x2a/0x70 ? do_sys_openat2+0xa2/0xe0 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Fix this by checking is_visible() before trying to touch the attribute.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/sysfb: Do not dereference NULL pointer in plane resetThe plane state in __drm_gem_reset_shadow_plane() can be NULL. Do notderef that pointer, but forward NULL to the other plane-reset helpers.Clears plane->state to NULL.v2:- fix typo in commit description (Javier)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/fpu: Ensure XFD state on signal deliverySean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53Chao further identified [2] a reproducible scenario involving signaldelivery: a non-AMX task is preempted by an AMX-enabled task whichmodifies the XFD MSR.When the non-AMX task resumes and reloads XSTATE with init values,a warning is triggered due to a mismatch between fpstate::xfd and theCPU's current XFD state. fpu__clear_user_states() does not currentlyre-synchronize the XFD state after such preemption.Invoke xfd_update_state() which detects and corrects the mismatch ifthere is a dynamic feature.This also benefits the sigreturn path, as fpu__restore_sig() may callfpu__clear_user_states() when the sigframe is inaccessible.[ dhansen: minor changelog munging ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix softlockup in ftrace_module_enableA soft lockup was observed when loading amdgpu module.If a module has a lot of tracable functions, multiple callsto kallsyms_lookup can spend too much time in RCU criticalsection and with disabled preemption, causing kernel panic.This is the same issue that was fixed incommit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARYkernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() toftrace_graph_set_hash()").Fix it the same way by adding cond_resched() in ftrace_module_enable.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:amd/amdkfd: enhance kfd process check in switch partitioncurrent switch partition only check if kfd_processes_table is empty.kfd_prcesses_table entry is deleted in kfd_process_notifier_release, butkfd_process tear down is in kfd_process_wq_release.consider two processes:Process A (workqueue) -> kfd_process_wq_release -> Access kfd_node memberProcess B switch partition -> amdgpu_xcp_pre_partition_switch -> amdgpu_amdkfd_device_fini_sw-> kfd_node tear down.Process A and B may trigger a race as shown in dmesg log.This patch is to resolve the race by adding an atomic kfd_process counterkfd_processes_count, it increment as create kfd process, decrement asfinish kfd_process_wq_release.v2: Put kfd_processes_count per kfd_dev, move decrement to kfd_process_destroy_pddsand bug fix. (Philip Yang)[3966658.307702] divide error: 0000 [#1] SMP NOPTI[3966658.350818] i10nm_edac[3966658.356318] CPU: 124 PID: 38435 Comm: kworker/124:0 Kdump: loaded Tainted[3966658.356890] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu][3966658.362839] nfit[3966658.366457] RIP: 0010:kfd_get_num_sdma_engines+0x17/0x40 [amdgpu][3966658.366460] Code: 00 00 e9 ac 81 02 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 48 8b 4f 08 48 8b b7 00 01 00 00 8b 81 58 26 03 00 99 be b8 01 00 00 80 b9 70 2e 00 00 00 74 0b 83 f8 02 ba 02 00 00[3966658.380967] x86_pkg_temp_thermal[3966658.391529] RSP: 0018:ffffc900a0edfdd8 EFLAGS: 00010246[3966658.391531] RAX: 0000000000000008 RBX: ffff8974e593b800 RCX: ffff888645900000[3966658.391531] RDX: 0000000000000000 RSI: ffff888129154400 RDI: ffff888129151c00[3966658.391532] RBP: ffff8883ad79d400 R08: 0000000000000000 R09: ffff8890d2750af4[3966658.391532] R10: 0000000000000018 R11: 0000000000000018 R12: 0000000000000000[3966658.391533] R13: ffff8883ad79d400 R14: ffffe87ff662ba00 R15: ffff8974e593b800[3966658.391533] FS: 0000000000000000(0000) GS:ffff88fe7f600000(0000) knlGS:0000000000000000[3966658.391534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[3966658.391534] CR2: 0000000000d71000 CR3: 000000dd0e970004 CR4: 0000000002770ee0[3966658.391535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[3966658.391535] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400[3966658.391536] PKRU: 55555554[3966658.391536] Call Trace:[3966658.391674] deallocate_sdma_queue+0x38/0xa0 [amdgpu][3966658.391762] process_termination_cpsch+0x1ed/0x480 [amdgpu][3966658.399754] intel_powerclamp[3966658.402831] kfd_process_dequeue_from_all_devices+0x5b/0xc0 [amdgpu][3966658.402908] kfd_process_wq_release+0x1a/0x1a0 [amdgpu][3966658.410516] coretemp[3966658.434016] process_one_work+0x1ad/0x380[3966658.434021] worker_thread+0x49/0x310[3966658.438963] kvm_intel[3966658.446041] ? process_one_work+0x380/0x380[3966658.446045] kthread+0x118/0x140[3966658.446047] ? __kthread_bind_mask+0x60/0x60[3966658.446050] ret_from_fork+0x1f/0x30[3966658.446053] Modules linked in: kpatch_20765354(OEK)[3966658.455310] kvm[3966658.464534] mptcp_diag xsk_diag raw_diag unix_diag af_packet_diag netlink_diag udp_diag act_pedit act_mirred act_vlan cls_flower kpatch_21951273(OEK) kpatch_18424469(OEK) kpatch_19749756(OEK)[3966658.473462] idxd_mdev[3966658.482306] kpatch_17971294(OEK) sch_ingress xt_conntrack amdgpu(OE) amdxcp(OE) amddrm_buddy(OE) amd_sched(OE) amdttm(OE) amdkcl(OE) intel_ifs iptable_mangle tcm_loop target_core_pscsi tcp_diag target_core_file inet_diag target_core_iblock target_core_user target_core_mod coldpgs kpatch_18383292(OEK) ip6table_nat ip6table_filter ip6_tables ip_set_hash_ipportip ip_set_hash_ipportnet ip_set_hash_ipport ip_set_bitmap_port xt_comment iptable_nat nf_nat iptable_filter ip_tables ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sn_core_odd(OE) i40e overlay binfmt_misc tun bonding(OE) aisqos(OE) aisqo---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: cadence: Check for the existence of cdns_pcie::ops before using itcdns_pcie::ops might not be populated by all the Cadence glue drivers. Thisis going to be true for the upcoming Sophgo platform which doesn't set theops.Hence, add a check to prevent NULL pointer dereference.[mani: reworded subject and description]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencingTheoretically it's an oopsable race, but I don't believe one can manageto hit it on real hardware; might become doable on a KVM, but it stillwon't be easy to attack.Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call ofput_unaligned_be64(), we can put that under ->d_lock and be done with that.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udp_tunnel: use netdev_warn() instead of netdev_WARN()netdev_WARN() uses WARN/WARN_ON to print a backtrace along withfile and line information. In this case, udp_tunnel_nic_register()returning an error is just a failed operation, not a kernel bug.udp_tunnel_nic_register() can fail due to a memory allocationfailure (kzalloc() or udp_tunnel_nic_alloc()).This is a normal runtime error and not a kernel bug.Replace netdev_WARN() with netdev_warn() accordingly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixupRaw IP packets have no MAC header, leaving skb->mac_header uninitialized.This can trigger kernel panics on ARM64 when xfrm or other subsystemsaccess the offset due to strict alignment checks.Initialize the MAC header to prevent such crashes.This can trigger kernel panics on ARM when running IPsec over theqmimux0 interface.Example trace: Internal error: Oops: 000000009600004f [#1] SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1 Hardware name: LS1028A RDB Board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : xfrm_input+0xde8/0x1318 lr : xfrm_input+0x61c/0x1318 sp : ffff800080003b20 Call trace: xfrm_input+0xde8/0x1318 xfrm6_rcv+0x38/0x44 xfrm6_esp_rcv+0x48/0xa8 ip6_protocol_deliver_rcu+0x94/0x4b0 ip6_input_finish+0x44/0x70 ip6_input+0x44/0xc0 ipv6_rcv+0x6c/0x114 __netif_receive_skb_one_core+0x5c/0x8c __netif_receive_skb+0x18/0x60 process_backlog+0x78/0x17c __napi_poll+0x38/0x180 net_rx_action+0x168/0x2f0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Add bpf_prog_run_data_pointers()syzbot found that cls_bpf_classify() is able to changetc_skb_cb(skb)->drop_reason triggering a warning in sk_skb_reason_drop().WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline]WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214struct tc_skb_cb has been added in commit ec624fe740b4 ("net/sched:Extend qdisc control block with tc control block"), which added a wronginteraction with db58ba459202 ("bpf: wire in data and data_end forcls_act_bpf").drop_reason was added later.Add bpf_prog_run_data_pointers() helper to save/restore the net_schedstorage colliding with BPF data_meta/data_end.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: remove two invalid BUG_ON()sThose can be triggered trivially by userspace.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: arm: scmi: Fix genpd leak on provider registration failureIf of_genpd_add_provider_onecell() fails during probe, the previouslycreated generic power domains are not removed, leading to a memory leakand potential kernel crash later in genpd_debug_add().Add proper error handling to unwind the initialized domains beforereturning from probe to ensure all resources are correctly released onfailure.Example crash trace observed without this fix: | Unable to handle kernel paging request at virtual address fffffffffffffc70 | CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1 #405 PREEMPT | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : genpd_debug_add+0x2c/0x160 | lr : genpd_debug_init+0x74/0x98 | Call trace: | genpd_debug_add+0x2c/0x160 (P) | genpd_debug_init+0x74/0x98 | do_one_initcall+0xd0/0x2d8 | do_initcall_level+0xa0/0x140 | do_initcalls+0x60/0xa8 | do_basic_setup+0x28/0x40 | kernel_init_freeable+0xe8/0x170 | kernel_init+0x2c/0x140 | ret_from_fork+0x10/0x20
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: add seqadj extension for natted connectionsSequence adjustment may be required for FTP traffic with PASV/EPSV modes.due to need to re-write packet payload (IP, port) on the ftp controlconnection. This can require changes to the TCP length and expectedseq / ack_seq.The easiest way to reproduce this issue is with PASV mode.Example ruleset:table inet ftp_nat { ct helper ftp_helper { type "ftp" protocol tcp l3proto inet } chain prerouting { type filter hook prerouting priority 0; policy accept; tcp dport 21 ct state new ct helper set "ftp_helper" }}table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { 192.168.100.1 : 192.168.13.2/32 } } chain postrouting { type nat hook postrouting priority 100 ; policy accept; tcp sport 21 snat ip prefix to ip saddr map { 192.168.13.2 : 192.168.100.1/32 } }}Note that the ftp helper gets assigned *after* the dnat setup.The inverse (nat after helper assign) is handled by an existingcheck in nf_nat_setup_info() and will not show the problem.Topoloy: +-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+ftp nat changes do not work as expected in this case:Connected to 192.168.100.1.[..]ftp> epsvEPSV/EPRT on IPv4 off.ftp> ls227 Entering passive mode (192,168,100,1,209,129).421 Service not available, remote server has closed connection.Kernel logs:Missing nfct_seqadj_ext_add() setup callWARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41[..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 ..Fix this by adding the required extension when a conntrack helper is assignedto a connection that has a nat binding.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mlx5: Fix default values in create CQCurrently, CQs without a completion function are assigned themlx5_add_cq_to_tasklet function by default. This is problematic sinceonly user CQs created through the mlx5_ib driver are intended to usethis function.Additionally, all CQs that will use doorbells instead of polling forcompletions must call mlx5_cq_arm. However, the default CQ creation flowleaves a valid value in the CQ's arm_db field, allowing FW to sendinterrupts to polling-only CQs in certain corner cases.These two factors would allow a polling-only kernel CQ to be triggeredby an EQ interrupt and call a completion function intended only for userCQs, causing a null pointer exception.Some areas in the driver have prevented this issue with one-off fixesbut did not address the root cause.This patch fixes the described issue by adding defaults to the create CQflow. It adds a default dummy completion function to protect againstnull pointer exceptions, and it sets an invalid command sequence numberby default in kernel CQs to prevent the FW from sending an interrupt tothe CQ until it is armed. User CQs are responsible for their owninitialization values.Callers of mlx5_core_create_cq are responsible for changing thecompletion function and arming the CQ per their needs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksm: use range-walk function to jump over holes in scan_get_next_rmap_itemCurrently, scan_get_next_rmap_item() walks every page address in a VMA tolocate mergeable pages. This becomes highly inefficient when scanninglarge virtual memory areas that contain mostly unmapped regions, causingksmd to use large amount of cpu without deduplicating much pages.This patch replaces the per-address lookup with a range walk usingwalk_page_range(). The range walker allows KSM to skip over entireunmapped holes in a VMA, avoiding unnecessary lookups. This problem waspreviously discussed in [1].Consider the following test program which creates a 32 TiB mapping in thevirtual address space but only populates a single page:#include #include #include /* 32 TiB */const size_t size = 32ul * 1024 * 1024 * 1024 * 1024;int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror("mmap() failed\n"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0;}$ ./ksm-sparse &$ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1hour in my test machine) scanning all the 32 TiB virtual address spacethat contain only one mapped page. This makes ksmd essentially deadlockednot able to deduplicate anything of value. With this patch ksmd walksonly the one mapped page and skips the rest of the 32 TiB virtual addressspace, making the scan fast using little cpu.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:timers: Fix NULL function pointer race in timer_shutdown_sync()There is a race condition between timer_shutdown_sync() and timerexpiration that can lead to hitting a WARN_ON in expire_timers().The issue occurs when timer_shutdown_sync() clears the timer functionto NULL while the timer is still running on another CPU. The racescenario looks like this:CPU0 CPU1 lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ...timer_shutdown_sync()lock_timer_base()// For now, will not detach the timer but only clear its function to NULLif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger expire_timers() WARN_ON_ONCE(!fn) // hit ...lock_timer_base()// Now timer will detachif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base()The problem is that timer_shutdown_sync() clears the timer functionregardless of whether the timer is currently running. This can leave apending timer with a NULL function pointer, which triggers theWARN_ON_ONCE(!fn) check in expire_timers().Fix this by only clearing the timer function when actually detaching thetimer. If the timer is running, leave the function pointer intact, which issafe because the timer will be properly detached when it finishes running.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix memory leak in smb3_fs_context_parse_param error pathAdd proper cleanup of ctx->source and fc->source to thecifs_parse_mount_err error handler. This ensures that memory allocatedfor the source strings is correctly freed on all error paths, matchingthe cleanup already performed in the success path bysmb3_cleanup_fs_context_contents().Pointers are also set to NULL after freeing to prevent potentialdouble-free issues.This change fixes a memory leak originally detected by syzbot. Theleak occurred when processing Opt_source mount options if an errorhappened after ctx->source and fc->source were successfullyallocated but before the function completed.The specific leak sequence was:1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory3. A subsequent error jumps to cifs_parse_mount_err4. The old error handler freed passwords but not the source strings,causing the memory to leak.This issue was not addressed by commit e8c73eb7db0a ("cifs: client:fix memory leak in smb3_fs_context_parse_param"), which only fixedleaks from repeated fsconfig() calls but not this error path.Patch updated with minor change suggested by kernel test robot
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: Fix proto fallback detection with BPFThe sockmap feature allows bpf syscall from userspace, or basedon bpf sockops, replacing the sk_prot of sockets during protocol stackprocessing with sockmap's custom read/write interfaces.'''tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot'''When the server has MPTCP enabled but the client sends a TCP SYNwithout MPTCP, subflow_syn_recv_sock() performs a fallback on thesubflow, replacing the subflow sk's sk_prot with the native sk_prot.'''subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override()'''Then, this subflow can be normally used by sockmap, which replaces thenative sk_prot with sockmap's custom sk_prot. The issue occurs when theuser executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops().Here, it uses sk->sk_prot to compare with the native sk_prot, but thisis incorrect when sockmap is used, as we may incorrectly setsk->sk_socket->ops.This fix uses the more generic sk_family for the comparison instead.Additionally, this also prevents a WARNING from occurring:result from ./scripts/decode_stacktrace.sh:------------[ cut here ]------------WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \(net/mptcp/protocol.c:4005)Modules linked in:...PKRU: 55555554Call Trace:do_accept (net/socket.c:1989)__sys_accept4 (net/socket.c:2028 net/socket.c:2057)__x64_sys_accept (net/socket.c:2067)x64_sys_call (arch/x86/entry/syscall_64.c:41)do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)RIP: 0033:0x7f87ac92b83d---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and weattempt to dereference it in tcm_loop_tpg_address_show() we will get asegfault, see below for an example. So, check tl_hba->sh beforedereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempool: fix poisoning order>0 pages with HIGHMEMThe kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283)Christoph found out this is due to the poisoning code not dealingproperly with CONFIG_HIGHMEM because only the first page is mapped butthen the whole potentially high-order page is accessed.We could give up on HIGHMEM here, but it's straightforward to fix thiswith a loop that's mapping, poisoning or checking and unmappingindividual pages.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/tegra: Add call to put_pid()Add a call to put_pid() corresponding to get_task_pid().host1x_memory_context_alloc() does not take ownership of the PID so weneed to free it here to avoid leaking.[mperttunen@nvidia.com: reword commit message]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:binfmt_misc: restore write access before closing files opened by open_exec()bm_register_write() opens an executable file using open_exec(), whichinternally calls do_open_execat() and denies write access on the file toavoid modification while it is being executed.However, when an error occurs, bm_register_write() closes the file usingfilp_close() directly. This does not restore the write permission, whichmay cause subsequent write operations on the same file to fail.Fix this by calling exe_file_allow_write_access() before filp_close() torestore the write permission properly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: route: Prevent rt_bind_exception() from rebinding stale fnheThe sit driver's packet transmission path calls: sit_tunnel_xmit() ->update_or_create_fnhe(), which lead to fnhe_remove_oldest() being calledto delete entries exceeding FNHE_RECLAIM_DEPTH+random.The race window is between fnhe_remove_oldest() selecting fnheX fordeletion and the subsequent kfree_rcu(). During this time, theconcurrent path's __mkroute_output() -> find_exception() can fetch thesoon-to-be-deleted fnheX, and rt_bind_exception() then binds it with anew dst using a dst_hold(). When the original fnheX is freed via RCU,the dst reference remains permanently leaked.CPU 0 CPU 1__mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak]This issue manifests as a device reference count leak and a warning indmesg when unregistering the net device: unregister_netdevice: waiting for sitX to become free. Usage count = NIdo Schimmel provided the simple test validation method [1].The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes().Since rt_bind_exception() checks this field, setting it to zero preventsthe stale fnhe from being reused and bound to a new dst just before itis freed.[1]ip netns add ns1ip -n ns1 link set dev lo upip -n ns1 address add 192.0.2.1/32 dev loip -n ns1 link add name dummy1 up type dummyip -n ns1 route add 192.0.2.2/32 dev dummy1ip -n ns1 link add name gretap1 up arp off type gretap \ local 192.0.2.1 remote 192.0.2.2ip -n ns1 route add 198.51.0.0/16 dev gretap1taskset -c 0 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &taskset -c 2 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &sleep 10ip netns pids ns1 | xargs killip netns del ns1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTDOn completion of i915_vma_pin_ww(), a synchronous variant ofdma_fence_work_commit() is called. When pinning a VMA to GGTT addressspace on a Cherry View family processor, or on a Broxton generation SoCwith VTD enabled, i.e., when stop_machine() is then called fromintel_ggtt_bind_vma(), that can potentially lead to lock inversion amongreservation_ww and cpu_hotplug locks.[86.861179] ======================================================[86.861193] WARNING: possible circular locking dependency detected[86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G U[86.861226] ------------------------------------------------------[86.861238] i915_module_loa/1432 is trying to acquire lock:[86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50[86.861290]but task is already holding lock:[86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915][86.862233]which lock already depends on the new lock.[86.862251]the existing dependency chain (in reverse order) is:[86.862265]-> #5 (reservation_ww_class_mutex){+.+.}-{3:3}:[86.862292] dma_resv_lockdep+0x19a/0x390[86.862315] do_one_initcall+0x60/0x3f0[86.862334] kernel_init_freeable+0x3cd/0x680[86.862353] kernel_init+0x1b/0x200[86.862369] ret_from_fork+0x47/0x70[86.862383] ret_from_fork_asm+0x1a/0x30[86.862399]-> #4 (reservation_ww_class_acquire){+.+.}-{0:0}:[86.862425] dma_resv_lockdep+0x178/0x390[86.862440] do_one_initcall+0x60/0x3f0[86.862454] kernel_init_freeable+0x3cd/0x680[86.862470] kernel_init+0x1b/0x200[86.862482] ret_from_fork+0x47/0x70[86.862495] ret_from_fork_asm+0x1a/0x30[86.862509]-> #3 (&mm->mmap_lock){++++}-{3:3}:[86.862531] down_read_killable+0x46/0x1e0[86.862546] lock_mm_and_find_vma+0xa2/0x280[86.862561] do_user_addr_fault+0x266/0x8e0[86.862578] exc_page_fault+0x8a/0x2f0[86.862593] asm_exc_page_fault+0x27/0x30[86.862607] filldir64+0xeb/0x180[86.862620] kernfs_fop_readdir+0x118/0x480[86.862635] iterate_dir+0xcf/0x2b0[86.862648] __x64_sys_getdents64+0x84/0x140[86.862661] x64_sys_call+0x1058/0x2660[86.862675] do_syscall_64+0x91/0xe90[86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e[86.862703]-> #2 (&root->kernfs_rwsem){++++}-{3:3}:[86.862725] down_write+0x3e/0xf0[86.862738] kernfs_add_one+0x30/0x3c0[86.862751] kernfs_create_dir_ns+0x53/0xb0[86.862765] internal_create_group+0x134/0x4c0[86.862779] sysfs_create_group+0x13/0x20[86.862792] topology_add_dev+0x1d/0x30[86.862806] cpuhp_invoke_callback+0x4b5/0x850[86.862822] cpuhp_issue_call+0xbf/0x1f0[86.862836] __cpuhp_setup_state_cpuslocked+0x111/0x320[86.862852] __cpuhp_setup_state+0xb0/0x220[86.862866] topology_sysfs_init+0x30/0x50[86.862879] do_one_initcall+0x60/0x3f0[86.862893] kernel_init_freeable+0x3cd/0x680[86.862908] kernel_init+0x1b/0x200[86.862921] ret_from_fork+0x47/0x70[86.862934] ret_from_fork_asm+0x1a/0x30[86.862947]-> #1 (cpuhp_state_mutex){+.+.}-{3:3}:[86.862969] __mutex_lock+0xaa/0xed0[86.862982] mutex_lock_nested+0x1b/0x30[86.862995] __cpuhp_setup_state_cpuslocked+0x67/0x320[86.863012] __cpuhp_setup_state+0xb0/0x220[86.863026] page_alloc_init_cpuhp+0x2d/0x60[86.863041] mm_core_init+0x22/0x2d0[86.863054] start_kernel+0x576/0xbd0[86.863068] x86_64_start_reservations+0x18/0x30[86.863084] x86_64_start_kernel+0xbf/0x110[86.863098] common_startup_64+0x13e/0x141[86.863114]-> #0 (cpu_hotplug_lock){++++}-{0:0}:[86.863135] __lock_acquire+0x16---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: netpoll: fix incorrect refcount handling causing incorrect cleanupcommit efa95b01da18 ("netpoll: fix use after free") incorrectlyignored the refcount and prematurely set dev->npinfo to NULL duringnetpoll cleanup, leading to improper behavior and memory leaks.Scenario causing lack of proper cleanup:1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one.2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev.3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak.Revert commit efa95b01da18 ("netpoll: fix use after free") and addsclarifying comments emphasizing that npinfo cleanup should only happenonce the refcount reaches zero, ensuring stable and correct netpollbehavior.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:most: usb: hdm_probe: Fix calling put_device() before device initializationThe early error path in hdm_probe() can jump to err_free_mdev before&mdev->dev has been initialized with device_initialize(). Callingput_device(&mdev->dev) there triggers a device core WARN and ends upinvoking kref_put(&kobj->kref, kobject_release) on an uninitializedkobject.In this path the private struct was only kmalloc'ed and the intendedrelease is effectively kfree(mdev) anyway, so free it directly insteadof calling put_device() on an uninitialized device.This removes the WARNING and fixes the pre-initialization error path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: check device's attached status in compat ioctlsSyzbot identified an issue [1] that crashes kernel, seemingly due tounexistent callback dev->get_valid_routes(). By all means, this shouldnot occur as said callback must always be set toget_zero_valid_routes() in __comedi_device_postconfig().As the crash seems to appear exclusively in i386 kernels, at least,judging from [1] reports, the blame lies with compat versionsof standard IOCTL handlers. Several of them are modified anddo not use comedi_unlocked_ioctl(). While functionality of theseioctls essentially copy their original versions, they do nothave required sanity check for device's attached status. This,in turn, leads to a possibility of calling select IOCTLs on adevice that has not been properly setup, even via COMEDI_DEVCONFIG.Doing so on unconfigured devices means that several crucial stepsare missed, for instance, specifying dev->get_valid_routes()callback.Fix this somewhat crudely by ensuring device's attached status beforeperforming any ioctls, improving logic consistency between modernand compat functions.[1] Syzbot report:BUG: kernel NULL pointer dereference, address: 0000000000000000...CR2: ffffffffffffffd6 CR3: 000000006c717000 CR4: 0000000000352ef0Call Trace: get_valid_routes drivers/comedi/comedi_fops.c:1322 [inline] parse_insn+0x78c/0x1970 drivers/comedi/comedi_fops.c:1401 do_insnlist_ioctl+0x272/0x700 drivers/comedi/comedi_fops.c:1594 compat_insnlist drivers/comedi/comedi_fops.c:3208 [inline] comedi_compat_ioctl+0x810/0x990 drivers/comedi/comedi_fops.c:3273 __do_compat_sys_ioctl fs/ioctl.c:695 [inline] __se_compat_sys_ioctl fs/ioctl.c:638 [inline] __ia32_compat_sys_ioctl+0x242/0x370 fs/ioctl.c:638 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: multiq3: sanitize config options in multiq3_attach()Syzbot identified an issue [1] in multiq3_attach() that induces atask timeout due to open() or COMEDI_DEVCONFIG ioctl operations,specifically, in the case of multiq3 driver.This problem arose when syzkaller managed to craft weird configurationoptions used to specify the number of channels in encoder subdevice.If a particularly great number is passed to s->n_chan inmultiq3_attach() via it->options[2], then multiple calls tomultiq3_encoder_reset() at the end of driver-specific attach() methodwill be running for minutes, thus blocking tasks and affected devicesas well.While this issue is most likely not too dangerous for real-lifedevices, it still makes sense to sanitize configuration inputs. Enablea sensible limit on the number of encoder chips (4 chips max, eachwith 2 channels) to stop this behaviour from manifesting.[1] Syzbot crash:INFO: task syz.2.19:6067 blocked for more than 143 seconds....Call Trace: context_switch kernel/sched/core.c:5254 [inline] __schedule+0x17c4/0x4d60 kernel/sched/core.c:6862 __schedule_loop kernel/sched/core.c:6944 [inline] schedule+0x165/0x360 kernel/sched/core.c:6959 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016 __mutex_lock_common kernel/locking/mutex.c:676 [inline] __mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760 comedi_open+0xc0/0x590 drivers/comedi/comedi_fops.c:2868 chrdev_open+0x4cc/0x5e0 fs/char_dev.c:414 do_dentry_open+0x953/0x13f0 fs/open.c:965 vfs_open+0x3b/0x340 fs/open.c:1097...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()Fix a race between inline data destruction and block mapping.The function ext4_destroy_inline_data_nolock() changes the inode datalayout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS.At the same time, another thread may execute ext4_map_blocks(), whichtests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks()or ext4_ind_map_blocks().Without i_data_sem protection, ext4_ind_map_blocks() may receive inodewith EXT4_INODE_EXTENTS flag and triggering assert.kernel BUG at fs/ext4/indirect.c:546!EXT4-fs (loop2): unmounting filesystem.invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTIHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546Call Trace: ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681 _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822 ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124 ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255 ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000 generic_perform_write+0x259/0x5d0 mm/filemap.c:3846 ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285 ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679 call_write_iter include/linux/fs.h:2271 [inline] do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735 do_iter_write+0x186/0x710 fs/read_write.c:861 vfs_iter_write+0x70/0xa0 fs/read_write.c:902 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685 do_splice_from fs/splice.c:763 [inline] direct_splice_actor+0x10f/0x170 fs/splice.c:950 splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896 do_splice_direct+0x1a9/0x280 fs/splice.c:1002 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, an unprivileged local users can crash avahi-daemon (with wide-area disabled) by creating record browsers with the AVAHI_LOOKUP_USE_WIDE_AREA flag set via D-Bus. This can be done by either callingthe RecordBrowserNew method directly or creating hostname/address/service resolvers/browsers that create those browsers internally themselves.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libavahi-client3 > 0-0 (version in image is 0.8-150400.7.26.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: udc: fix use-after-free in usb_gadget_state_workA race condition during gadget teardown can lead to a use-after-freein usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_workThe fundamental race occurs because a concurrent event (e.g., aninterrupt) can call usb_gadget_set_state() and schedule gadget->workat any time during the cleanup process in usb_del_gadget().Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue afterdevice removal") attempted to fix this by moving flush_work() to afterdevice_del(). However, this does not fully solve the race, as a newwork item can still be scheduled *after* flush_work() completes butbefore the gadget's memory is freed, leading to the same use-after-free.This patch fixes the race condition robustly by introducing a 'teardown'flag and a 'state_lock' spinlock to the usb_gadget struct. The flag isset during cleanup in usb_del_gadget() *before* calling flush_work() toprevent any new work from being scheduled once cleanup has commenced.The scheduling site, usb_gadget_set_state(), now checks this flag underthe lock before queueing the work, thus safely closing the race window.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call pathsThis patch addresses a race condition caused by unsynchronizedexecution of multiple call paths invoking `dwc3_remove_requests()`,leading to premature freeing of USB requests and subsequent crashes.Three distinct execution paths interact with `dwc3_remove_requests()`:Path 1:Triggered via `dwc3_gadget_reset_interrupt()` during USB resethandling. The call stack includes:- `dwc3_ep0_reset_state()`- `dwc3_ep0_stall_and_restart()`- `dwc3_ep0_out_start()`- `dwc3_remove_requests()`- `dwc3_gadget_del_and_unmap_request()`Path 2:Also initiated from `dwc3_gadget_reset_interrupt()`, but through`dwc3_stop_active_transfers()`. The call stack includes:- `dwc3_stop_active_transfers()`- `dwc3_remove_requests()`- `dwc3_gadget_del_and_unmap_request()`Path 3:Occurs independently during `adb root` execution, which triggersUSB function unbind and bind operations. The sequence includes:- `gserial_disconnect()`- `usb_ep_disable()`- `dwc3_gadget_ep_disable()`- `dwc3_remove_requests()` with `-ESHUTDOWN` statusPath 3 operates asynchronously and lacks synchronization with Paths1 and 2. When Path 3 completes, it disables endpoints and frees 'out'requests. If Paths 1 or 2 are still processing these requests,accessing freed memory leads to a crash due to use-after-free conditions.To fix this added check for request completion and skip processingif already completed and added the request status for ep0 while queue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_eem: Fix memory leak in eem_unwrapThe existing code did not handle the failure case of usb_ep_queue in thecommand path, potentially leading to memory leaks.Improve error handling to free all allocated resources on usb_ep_queuefailure. This patch continues to use goto logic for error handling, as theexisting error handling is complex and not easily adaptable to auto-cleanuphelpers.kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:most: usb: fix double free on late probe failureThe MOST subsystem has a non-standard registration function which freesthe interface on registration failures and on deregistration.This unsurprisingly leads to bugs in the MOST drivers, and a couple ofrecent changes turned a reference underflow and use-after-free in theUSB driver into several double free and a use-after-free on late probefailures.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix memory leak in cifs_construct_tcon()When having a multiuser mount with domain= specified and usingcifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname,so it needs to be freed before leaving cifs_construct_tcon().This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setupProtect vga_switcheroo_client_fb_set() with console lock. Avoids OOBaccess in fbcon_remap_all(). Without holding the console lock the callraces with switching outputs.VGA switcheroo calls fbcon_remap_all() when switching clients. The fbconfunction uses struct fb_info.node, which is set by register_framebuffer().As the fb-helper code currently sets up VGA switcheroo before registeringthe framebuffer, the value of node is -1 and therefore not a legal value.For example, fbcon uses the value within set_con2fb_map() [1] as an indexinto an array.Moving vga_switcheroo_client_fb_set() after register_framebuffer() canresult in VGA switching that does not switch fbcon correctly.Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(),which already holds the console lock. Fbdev calls fbcon_fb_registered()from within register_framebuffer(). Serializes the helper with VGAswitcheroo's call to fbcon_remap_all().Although vga_switcheroo_client_fb_set() takes an instance of struct fb_infoas parameter, it really only needs the contained fbcon state. Moving thecall to fbcon initialization is therefore cleaner than before. Only amdgpu,i915, nouveau and radeon support vga_switcheroo. For all other drivers,this change does nothing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix crash in process_v2_sparse_read() for encrypted directoriesThe crash in process_v2_sparse_read() for fscrypt-encrypted directorieshas been reported. Issue takes place for Ceph msgr2 protocol in securemode. It can be reproduced by the steps:sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure(1) mkdir /mnt/cephfs/fscrypt-test-3(2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3(3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3(4) fscrypt lock /mnt/cephfs/fscrypt-test-3(5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3(6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar(7) Issue has been triggered[ 408.072247] ------------[ cut here ]------------[ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865ceph_con_v2_try_read+0x4b39/0x72f0[ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_commonintel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discoverypmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypasspolyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouseserio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfgpata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore[ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+[ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.17.0-5.fc42 04/01/2014[ 408.072310] Workqueue: ceph-msgr ceph_con_workfn[ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0[ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f88e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85[ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246[ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38[ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000[ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8[ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8[ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000[ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000)knlGS:0000000000000000[ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0[ 408.072336] PKRU: 55555554[ 408.072337] Call Trace:[ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10[ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10[ 408.072347] ? _raw_spin_unlock+0xe/0x40[ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830[ 408.072353] ? __kasan_check_write+0x14/0x30[ 408.072357] ? mutex_lock+0x84/0xe0[ 408.072359] ? __pfx_mutex_lock+0x10/0x10[ 408.072361] ceph_con_workfn+0x27e/0x10e0[ 408.072364] ? metric_delayed_work+0x311/0x2c50[ 408.072367] process_one_work+0x611/0xe20[ 408.072371] ? __kasan_check_write+0x14/0x30[ 408.072373] worker_thread+0x7e3/0x1580[ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10[ 408.072378] ? __pfx_worker_thread+0x10/0x10[ 408.072381] kthread+0x381/0x7a0[ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10[ 408.072385] ? __pfx_kthread+0x10/0x10[ 408.072387] ? __kasan_check_write+0x14/0x30[ 408.072389] ? recalc_sigpending+0x160/0x220[ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50[ 408.072394] ? calculate_sigpending+0x78/0xb0[ 408.072395] ? __pfx_kthread+0x10/0x10[ 408.072397] ret_from_fork+0x2b6/0x380[ 408.072400] ? __pfx_kthread+0x10/0x10[ 408.072402] ret_from_fork_asm+0x1a/0x30[ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]---[ 408.072418] Oops: general protection fault, probably for non-canonicaladdress 0xdffffc00000000---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: atlantic: fix fragment overflow handling in RX pathThe atlantic driver can receive packets with more than MAX_SKB_FRAGS (17)fragments when handling large multi-descriptor packets. This causes anout-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic.The issue occurs because the driver doesn't check the total number offragments before calling skb_add_rx_frag(). When a packet requires morethan MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds.Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE,then all fragments are accounted for. And reusing the existing check toprevent the overflow earlier in the code path.This crash occurred in production with an Aquantia AQC113 10G NIC.Stack trace from production environment:```RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 4889 fa 83RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX:fffffffe0a0c8000RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI:0000000000037a40RBP: 0000000000000024 R08: 0000000000000000 R09:0000000000000021R10: 0000000000000848 R11: 0000000000000000 R12:ffffa9bec02a8e24R13: ffff925ad8615570 R14: 0000000000000000 R15:ffff925b22e80a00FS: 0000000000000000(0000)GS:ffff925e47880000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4:0000000000f72ef0PKRU: 55555554Call Trace:aq_ring_rx_clean+0x175/0xe60 [atlantic]? aq_ring_rx_clean+0x14d/0xe60 [atlantic]? aq_ring_tx_clean+0xdf/0x190 [atlantic]? kmem_cache_free+0x348/0x450? aq_vec_poll+0x81/0x1d0 [atlantic]? __napi_poll+0x28/0x1c0? net_rx_action+0x337/0x420```Changes in v4:- Add Fixes: tag to satisfy patch validation requirements.Changes in v3:- Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sxgbe: fix potential NULL dereference in sxgbe_rx()Currently, when skb is null, the driver prints an error and thendereferences skb on the next line.To fix this, let's add a 'break' after the error message to switchto sxgbe_rx_refill(), which is similar to the approach taken by theother drivers in this particular case, e.g. calxeda with xgmac_rx().Found during a code review.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: intel: punit_ipc: fix memory corruptionThis passes the address of the pointer "&punit_ipcdev" when the intentwas to pass the pointer itself "punit_ipcdev" (without the ampersand).This means that the: complete(&ipcdev->cmd_complete);in intel_punit_ioc() will write to a wrong memory address corrupting it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: kvaser_usb: leaf: Fix potential infinite loop in command parsersThe `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback`functions contain logic to zero-length commands. These commands are usedto align data to the USB endpoint's wMaxPacketSize boundary.The driver attempts to skip these placeholders by aligning the bufferposition `pos` to the next packet boundary using `round_up()` function.However, if zero-length command is found exactly on a packet boundary(i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up`function will return the unchanged value of `pos`. This prevents `pos`to be increased, causing an infinite loop in the parsing logic.This patch fixes this in the function by using `pos + 1` instead.This ensures that even if `pos` is on a boundary, the calculation isbased on `pos + 1`, forcing `round_up()` to always return the nextaligned boundary.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: accel: bmc150: Fix irq assumption regressionThe code in bmc150-accel-core.c unconditionally callsbmc150_accel_set_interrupt() in the iio_buffer_setup_ops,such as on the runtime PM resume path giving a kernelsplat like this if the device has no interrupts:Unable to handle kernel NULL pointer dereference at virtual address 00000001 when readPC is at bmc150_accel_set_interrupt+0x98/0x194LR is at __pm_runtime_resume+0x5c/0x64(...)Call trace:bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc__iio_update_buffers from enable_store+0x84/0xc8enable_store from kernfs_fop_write_iter+0x154/0x1b4This bug seems to have been in the driver since the beginning,but it only manifests recently, I do not know why.Store the IRQ number in the state struct, as this is a commonpattern in other drivers, then use this to determine if we haveIRQ support or not.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:locking/spinlock/debug: Fix data-race in do_raw_write_lockKCSAN reports:BUG: KCSAN: data-race in do_raw_write_lock / do_raw_write_lockwrite (marked) to 0xffff800009cf504c of 4 bytes by task 1102 on cpu 1: do_raw_write_lock+0x120/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_forkread to 0xffff800009cf504c of 4 bytes by task 1103 on cpu 0: do_raw_write_lock+0x88/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_forkvalue changed: 0xffffffff -> 0x00000001Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 1103 Comm: kworker/u4:1 6.1.111Commit 1a365e822372 ("locking/spinlock/debug: Fix various data races") hasadressed most of these races, but seems to be not consistent/not complete.>From do_raw_write_lock() only debug_write_lock_after() part has beenconverted to WRITE_ONCE(), but not debug_write_lock_before() part.Do it now.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corruptedThere's issue when file system corrupted:------------[ cut here ]------------kernel BUG at fs/jbd2/transaction.c:1289!Oops: invalid opcode: 0000 [#1] SMP KASAN PTICPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-nextRIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0RSP: 0018:ffff888117aafa30 EFLAGS: 00010202RAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534RDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010RBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000R13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0Call Trace: __ext4_journal_get_create_access+0x42/0x170 ext4_getblk+0x319/0x6f0 ext4_bread+0x11/0x100 ext4_append+0x1e6/0x4a0 ext4_init_new_dir+0x145/0x1d0 ext4_mkdir+0x326/0x920 vfs_mkdir+0x45c/0x740 do_mkdirat+0x234/0x2f0 __x64_sys_mkdir+0xd6/0x120 do_syscall_64+0x5f/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe above issue occurs with us in errors=continue mode when accompanied bystorage failures. There have been many inconsistencies in the file systemdata.In the case of file system data inconsistency, for example, if the blockbitmap of a referenced block is not set, it can lead to the situation wherea block being committed is allocated and used again. As a result, thefollowing condition will not be satisfied then trigger BUG_ON. Of course,it is entirely possible to construct a problematic image that can triggerthis BUG_ON through specific operations. In fact, I have constructed suchan image and easily reproduced this issue.Therefore, J_ASSERT() holds true only under ideal conditions, but it maynot necessarily be satisfied in exceptional scenarios. Using J_ASSERT()directly in abnormal situations would cause the system to crash, which isclearly not what we want. So here we directly trigger a JBD abort insteadof immediately invoking BUG_ON.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi()The acpi_get_first_physical_node() function can return NULL, in whichcase the get_device() function also returns NULL, but this value isthen dereferenced without checking,so add a check to prevent a crash.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: dice: fix buffer overflow in detect_stream_formats()The function detect_stream_formats() reads the stream_count value directlyfrom a FireWire device without validating it. This can lead toout-of-bounds writes when a malicious device provides a stream_count valuegreater than MAX_STREAMS.Fix by applying the same validation to both TX and RX stream counts indetect_stream_formats().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalidFixes a crash when layout is null during this call stack:write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inodepnfs_set_layoutcommit relies on the lseg refcount to keep the layoutaround. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attemptto reference a null layout.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: Protect regulator_supply_alias_list with regulator_list_mutexregulator_supply_alias_list was accessed without any locking inregulator_supply_alias(), regulator_register_supply_alias(), andregulator_unregister_supply_alias(). Concurrent registration,unregistration and lookups can race, leading to:1 use-after-free if an alias entry is removed while being read,2 duplicate entries when two threads register the same alias,3 inconsistent alias mappings observed by consumers.Protect all traversals, insertions and deletions onregulator_supply_alias_list with the existing regulator_list_mutex.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix racy bitfield write in btrfs_clear_space_info_full()From the memory-barriers.txt document regarding memory barrier orderingguarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field.btrfs_space_info has a bitfield sharing an underlying word consisting ofthe fields full, chunk_alloc, and flush:struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ...Therefore, to be safe from parallel read-modify-writes losing a write toone of the bitfield members protected by a lock, all writes to all thebitfields must use the lock. They almost universally do, except forbtrfs_clear_space_info_full() which iterates over the space_infos andwrites out found->full = 0 without a lock.Imagine that we have one thread completing a transaction in which wefinished deleting a block_group and are thus callingbtrfs_clear_space_info_full() while simultaneously the data reclaimticket infrastructure is running do_async_reclaim_data_space(): T1 T2btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1and now data_sinfo->flush is 1 but the reclaim worker has exited. Thisbreaks the invariant that flush is 0 iff there is no work queued orrunning. Once this invariant is violated, future allocations that gointo __reserve_bytes() will add tickets to space_info->tickets but willsee space_info->flush is set to 1 and not queue the work. After this,they will block forever on the resulting ticket, as it is now impossibleto kick the worker again.I also confirmed by looking at the assembly of the affected kernel thatit is doing RMW operations. For example, to set the flush (3rd) bit to 0,the assembly is: andb $0xfb,0x60(%rbx)and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax)So I think this is really a bug on practical systems. I have observeda number of systems in this exact state, but am currently unable toreproduce it.Rather than leaving this footgun lying around for the future, takeadvantage of the fact that there is room in the struct anyway, and thatit is already quite large and simply change the three bitfield members tobools. This avoids writes to space_info->full having any effect on---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()The rtl8187_rx_cb() calculates the rx descriptor header addressby subtracting its size from the skb tail pointer.However, it does not validate if the received packet(skb->len from urb->actual_length) is large enough to contain thisheader.If a truncated packet is received, this will lead to a bufferunderflow, reading memory before the start of the skb data area,and causing a kernel panic.Add length checks for both rtl8187 and rtl8187b descriptor headersbefore attempting to access them, dropping the packet cleanly if thecheck fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check skb->transport_header is set in bpf_skb_check_mtuThe bpf_skb_check_mtu helper needs to use skb->transport_header whenthe BPF_MTU_CHK_SEGS flag is used: bpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS)The transport_header is not always set. There is a WARN_ON_ONCEreport when CONFIG_DEBUG_NET is enabled + skb->gso_size is set +bpf_prog_test_run is used:WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skbFor a normal ingress skb (not test_run), skb_reset_transport_headeris performed but there is plan to avoid setting it as described incommit 2170a1f09148 ("net: no longer reset transport_header in __netif_receive_skb_core()").This patch fixes the bpf helper by checkingskb_transport_header_was_set(). The check is done just beforeskb->transport_header is used, to avoid breaking the existing bpf prog.The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' justto avoid crashing the whole kernel due to a filesystem corruption.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: defer config unlock in nbd_genl_connectThere is one use-after-free warning when running NBD_CMD_CONNECT andNBD_CLEAR_SOCK:nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF open nbd // config_refs=3 recv_work done // config_refs=2 NBD_CLEAR_SOCK // config_refs=1 close nbd // config_refs=0 refcount_inc -> uaf------------[ cut here ]------------refcount_t: addition on 0; use-after-free.WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790The issue can be easily reproduced by adding a small delay beforerefcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags);+ printk("before sleep\n");+ mdelay(5 * 1000);+ printk("after sleep\n"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouseThe following warning appears when running syzkaller, and this issue alsoexists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2The WARNING occurs when two processes concurrently write to the mac-hidemulation sysctl, causing a race condition in mac_hid_toggle_emumouse().Both processes read old_val=0, then both try to register the input handler,leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock()Fix this by moving the old_val read inside the mutex lock region.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: smartpqi: Fix device resources accessed after device removalCorrect possible race conditions during device removal.Previously, a scheduled work item to reset a LUN could still executeafter the device was removed, leading to use-after-free and otherresource access issues.This race condition occurs because the abort handler may schedule a LUNreset concurrently with device removal via sdev_destroy(), leading touse-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: defer config put in recv_workThere is one uaf issue in recv_work when running NBD_CLEAR_SOCK andNBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAFOr only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAFCommit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying thewaiter") moved nbd_config_put() to run before waking up the waiter inrecv_work, in order to ensure that nbd_start_device_ioctl() would notbe woken up while nbd->task_recv was still uncleared.However, in nbd_start_device_ioctl(), after being woken up it explicitlycalls flush_workqueue() to make sure all current works are finished.Therefore, there is no need to move the config put ahead of the wakeup.Move nbd_config_put() to the end of recv_work, so that the reference isheld for the whole lifetime of the worker thread. This makes sure theconfig cannot be freed while recv_work is still running, even if clear+ reconfigure interleave.In addition, we don't need to worry about recv_work dropping the lastnbd_put (which causes deadlock):path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_workpath B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix stackmap overflow check in __bpf_get_stackid()Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid()when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix null deref on srq->rq.queue after resize failureA NULL pointer dereference can occur in rxe_srq_chk_attr() whenibv_modify_srq() is invoked twice in succession under certain errorconditions. The first call may fail in rxe_queue_resize(), which leadsrxe_srq_from_attr() to set srq->rq.queue = NULL. The second call thentriggers a crash (null deref) when accessingsrq->rq.queue->buf->index_mask.Call Trace:rxe_modify_srq+0x170/0x480 [rdma_rxe]? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe]? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs]? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs]ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs]? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs]? tryinc_node_nr_active+0xe6/0x150? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs]? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs]? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs]? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs]? __pfx___raw_spin_lock_irqsave+0x10/0x10? __pfx_do_vfs_ioctl+0x10/0x10? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs]? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs]__x64_sys_ioctl+0x138/0x1c0do_syscall_64+0x82/0x250? fdget_pos+0x58/0x4c0? ksys_write+0xf3/0x1c0? __pfx_ksys_write+0x10/0x10? do_syscall_64+0xc8/0x250? __pfx_vm_mmap_pgoff+0x10/0x10? fget+0x173/0x230? fput+0x2a/0x80? ksys_mmap_pgoff+0x224/0x4c0? do_syscall_64+0xc8/0x250? do_user_addr_fault+0x37b/0xfe0? clear_bhb_loop+0x50/0xa0? clear_bhb_loop+0x50/0xa0? clear_bhb_loop+0x50/0xa0entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix peer HE MCS assignmentIn ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent tofirmware as receive MCS while peer's receive MCS sent as transmit MCS,which goes against firmwire's definition.While connecting to a misbehaved AP that advertises 0xffff (meaning notsupported) for 160 MHz transmit MCS map, firmware crashes due to 0xffffis assigned to he_mcs->rx_mcs_set field. Ext Tag: HE Capabilities [...] Supported HE-MCS and NSS Set [...] Rx and Tx MCS Maps 160 MHz [...] Tx HE-MCS Map 160 MHz: 0xffffSwap the assignment to fix this issue.As the HE rate control mask is meant to limit our own transmit MCS, itneeds to go via he_mcs->rx_mcs_set field. With the aforementioned swappingdone, change is needed as well to apply it to the peer's receive MCS.Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_idUse check_add_overflow() to guard against potential integer overflowswhen adding the binary blob lengths and the size of an asymmetric_key_idstructure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents apossible buffer overflow when copying data from potentially maliciousX.509 certificate fields that can be arbitrarily large, such as ASN.1INTEGER serial numbers, issuer names, etc.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Do not let BPF test infra emit invalid GSO types to stackYinhao et al. reported that their fuzzer tool was able to trigger askb_warn_bad_offload() from netif_skb_features() -> gso_features_check().When a BPF program - triggered via BPF test infra - pushes the packetto the loopback device via bpf_clone_redirect() then mentioned offloadwarning can be seen. GSO-related features are then rightfully disabled.We get into this situation due to convert___skb_to_skb() settinggso_segs and gso_size but not gso_type. Technically, it makes sensethat this warning triggers since the GSO properties are malformed dueto the gso_type. Potentially, the gso_type could be marked non-trustworthythrough setting it at least to SKB_GSO_DODGY without any other specificassumptions, but that also feels wrong given we should not go furtherinto the GSO engine in the first place.The checks were added in 121d57af308d ("gso: validate gso_type in GSOhandlers") because there were malicious (syzbot) senders that combinea protocol with a non-matching gso_type. If we would want to drop suchpackets, gso_features_check() currently only returns feature flags vianetif_skb_features(), so one location for potentially dropping such skbscould be validate_xmit_unreadable_skb(), but then otoh it would bean additional check in the fast-path for a very corner case. Givenbpf_clone_redirect() is the only place where BPF test infra could emitsuch packets, lets reject them right there.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smack: fix bug: unprivileged task can create labelsIf an unprivileged task is allowed to relabel itself(/smack/relabel-self is not empty),it can freely create new labels by writing theirnames into own /proc/PID/attr/smack/currentThis occurs because do_setattr() importsthe provided label in advance,before checking "relabel-self" list.This change ensures that the "relabel-self" listis checked before importing the label.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ima: Handle error code returned by ima_filter_rule_match()In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due tothe rule being NULL, the function incorrectly skips the 'if (!rc)' checkand sets 'result = true'. The LSM rule is considered a match, causingextra files to be measured by IMA.This issue can be reproduced in the following scenario:After unloading the SELinux policy module via 'semodule -d', if an IMAmeasurement is triggered before ima_lsm_rules is updated,in ima_match_rules(), the first call to ima_filter_rule_match() returns-ESTALE. This causes the code to enter the 'if (rc == -ESTALE &&!rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. Inima_lsm_copy_rule(), since the SELinux module has been removed, the rulebecomes NULL, and the second call to ima_filter_rule_match() returns-ENOENT. This bypasses the 'if (!rc)' check and results in a false match.Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that errorcodes like -ENOENT do not bypass the check and accidentally result in asuccessful match.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vgem-fence: Fix potential deadlock on releaseA timer that expires a vgem fence automatically in 10 seconds is nowreleased with timer_delete_sync() from fence->ops.release() called on lastdma_fence_put(). In some scenarios, it can run in IRQ context, which isnot safe unless TIMER_IRQSAFE is used. One potentially risky scenario wasdemonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, whileworking on new IGT subtests syncobj_timeline@stress-* as user spacereplacements of some problematic test cases of a dma-fence-chain selftest[1].[117.004338] ================================[117.004340] WARNING: inconsistent lock state[117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U[117.004346] --------------------------------[117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.[117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes:[117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190[117.004361] {HARDIRQ-ON-W} state was registered at:[117.004363] lock_acquire+0xc4/0x2e0[117.004366] call_timer_fn+0x80/0x2a0[117.004368] __run_timers+0x231/0x310[117.004370] run_timer_softirq+0x76/0xe0[117.004372] handle_softirqs+0xd4/0x4d0[117.004375] __irq_exit_rcu+0x13f/0x160[117.004377] irq_exit_rcu+0xe/0x20[117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0[117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20[117.004385] cpuidle_enter_state+0x12b/0x8a0[117.004388] cpuidle_enter+0x2e/0x50[117.004393] call_cpuidle+0x22/0x60[117.004395] do_idle+0x1fd/0x260[117.004398] cpu_startup_entry+0x29/0x30[117.004401] start_secondary+0x12d/0x160[117.004404] common_startup_64+0x13e/0x141[117.004407] irq event stamp: 2282669[117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80[117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0[117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18[117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160[117.004426]other info that might help us debug this:[117.004429] Possible unsafe locking scenario:[117.004432] CPU0[117.004433] ----[117.004434] lock((&fence->timer));[117.004436] [117.004438] lock((&fence->timer));[117.004440] *** DEADLOCK ***[117.004443] 1 lock held by swapper/0/0:[117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0[117.004450]stack backtrace:[117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary)[117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER[117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023[117.004456] Call Trace:[117.004456] [117.004457] dump_stack_lvl+0x91/0xf0[117.004460] dump_stack+0x10/0x20[117.004461] print_usage_bug.part.0+0x260/0x360[117.004463] mark_lock+0x76e/0x9c0[117.004465] ? register_lock_class+0x48/0x4a0[117.004467] __lock_acquire+0xbc3/0x2860[117.004469] lock_acquire+0xc4/0x2e0[117.004470] ? __timer_delete_sync+0x4b/0x190[117.004472] ? __timer_delete_sync+0x4b/0x190[117.004473] __timer_delete_sync+0x68/0x190[117.004474] ? __timer_delete_sync+0x4b/0x190[117.004475] timer_delete_sync+0x10/0x20[117.004476] vgem_fence_release+0x19/0x30 [vgem][117.004478] dma_fence_release+0xc1/0x3b0[117.004480] ? dma_fence_release+0xa1/0x3b0[117.004481] dma_fence_chain_release+0xe7/0x130[117.004483] dma_fence_release+0xc1/0x3b0[117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80[117.004485] dma_fence_chain_irq_work+0x59/0x80[117.004487] irq_work_single+0x75/0xa0[117.004490] irq_work_r---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If thesubsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the functionreturns an error without freeing sskb, leading to a memory leak.Fix this by calling dev_kfree_skb() on sskb in the error handling pathto ensure it is properly released.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: Verify inode mode when loading from disksyzbot is reporting that S_IFMT bits of inode->i_mode can become bogus whenthe S_IFMT bits of the 16bits "mode" field loaded from disk are corrupted.According to [1], the permissions field was treated as reserved in Mac OS8 and 9. According to [2], the reserved field was explicitly initializedwith 0, and that field must remain 0 as long as reserved. Therefore, whenthe "mode" field is not 0 (i.e. no longer reserved), the file must beS_IFDIR if dir == 1, and the file must be one of S_IFREG/S_IFLNK/S_IFCHR/S_IFBLK/S_IFIFO/S_IFSOCK if dir == 0.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: only set free_cpus for online runqueuesCommit 16b269436b72 ("sched/deadline: Modify cpudl::free_cpusto reflect rd->online") introduced the cpudl_set/clear_freecpufunctions to allow the cpu_dl::free_cpus mask to be manipulatedby the deadline scheduler class rq_on/offline callbacks so themask would also reflect this state.Commit 9659e1eeee28 ("sched/deadline: Remove cpu_active_maskfrom cpudl_find()") removed the check of the cpu_active_mask tosave some processing on the premise that the cpudl::free_cpusmask already reflected the runqueue online state.Unfortunately, there are cases where it is possible for thecpudl_clear function to set the free_cpus bit for a CPU when thedeadline runqueue is offline. When this occurs while a CPU isconnected to the default root domain the flag may retain the badstate after the CPU has been unplugged. Later, a different CPUthat is transitioning through the default root domain may push adeadline task to the powered down CPU when cpudl_find sees itsfree_cpus bit is set. If this happens the task will not have theopportunity to run.One example is outlined here:https://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.comAnother occurs when the last deadline task is migrated from aCPU that has an offlined runqueue. The dequeue_task member ofthe deadline scheduler class will eventually call cpudl_clearand set the free_cpus bit for the CPU.This commit modifies the cpudl_clear function to be aware of theonline state of the deadline runqueue so that the free_cpus maskcan be updated appropriately.It is no longer necessary to manage the mask outside of thecpudl_set/clear functions so the cpudl_set/clear_freecpufunctions are removed. In addition, since the free_cpus mask isnow only updated under the cpudl lock the code was changed touse the non-atomic __cpumask functions.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Reset t_task_cdb pointer in error caseIf allocation of cmd->t_task_cdb fails, it remains NULL but is laterdereferenced in the 'err' path.In case of error, reset NULL t_task_cdb value to point at the defaultfixed-size buffer.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-mixer: us16x08: validate meter packet indicesget_meter_levels_from_urb() parses the 64-byte meter packets sent bythe device and fills the per-channel arrays meter_level[],comp_level[] and master_level[] in struct snd_us16x08_meter_store.Currently the function derives the channel index directly from themeter packet (MUB2(meter_urb, s) - 1) and uses it to index thosearrays without validating the range. If the packet contains anegative or out-of-range channel number, the driver may write pastthe end of these arrays.Introduce a local channel variable and validate it before updating thearrays. We reject negative indices, limit meter_level[] andcomp_level[] to SND_US16X08_MAX_CHANNELS, and guard master_level[]updates with ARRAY_SIZE(master_level).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:char: applicom: fix NULL pointer dereference in ac_ioctlDiscovered by Atuin - Automated Vulnerability Discovery Engine.In ac_ioctl, the validation of IndexCard and the check for a validRamIO pointer are skipped when cmd is 6. However, the functionunconditionally executes readb(apbs[IndexCard].RamIO + VERS) at theend.If cmd is 6, IndexCard may reference a board that does not exist(where RamIO is NULL), leading to a NULL pointer dereference.Fix this by skipping the readb access when cmd is 6, as thiscommand is a global information query and does not target a specificboard context.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: vidtv: initialize local pointers upon transfer of memory ownershipvidtv_channel_si_init() creates a temporary list (program, service, event)and ownership of the memory itself is transferred to the PAT/SDT/EITtables through vidtv_psi_pat_program_assign(),vidtv_psi_sdt_service_assign(), vidtv_psi_eit_event_assign().The problem here is that the local pointer where the memory ownershiptransfer was completed is not initialized to NULL. This causes thevidtv_psi_pmt_create_sec_for_each_pat_entry() function to fail, andin the flow that jumps to free_eit, the memory that was freed byvidtv_psi_*_table_destroy() can be accessed again byvidtv_psi_*_event_destroy() due to the uninitialized local pointer, so itis freed once again.Therefore, to prevent use-after-free and double-free vulnerability,local pointers must be initialized to NULL when transferring memoryownership.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: fix filename leak in __io_openat_prep() __io_openat_prep() allocates a struct filename using getname(). However,for the condition of the file being installed in the fixed file table aswell as having O_CLOEXEC flag set, the function returns early. At thatpoint, the request doesn't have REQ_F_NEED_CLEANUP flag set. Due to this,the memory for the newly allocated struct filename is not cleaned up,causing a memory leak.Fix this by setting the REQ_F_NEED_CLEANUP for the request just after thesuccessful getname() call, so that when the request is torn down, thefilename will be cleaned up, along with other resources needing cleanup.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: ets: Remove drr class from the active list if it changes to strictWhenever a user issues an ets qdisc change command, transforming adrr class into a strict one, the ets code isn't checking whether thatclass was in the active list and removing it. This means that, if auser changes a strict class (which was in the active list) back to a drrone, that class will be added twice to the active list [1].Doing so with the following commands:tc qdisc add dev lo root handle 1: ets bands 2 strict 1tc qdisc add dev lo parent 1:2 handle 20: \ tbf rate 8bit burst 100b latency 1stc filter add dev lo parent 1: basic classid 1:2ping -c1 -W0.01 -s 56 127.0.0.1tc qdisc change dev lo root handle 1: ets bands 2 strict 2tc qdisc change dev lo root handle 1: ets bands 2 strict 1ping -c1 -W0.01 -s 56 127.0.0.1Will trigger the following splat with list debug turned on:[ 59.279014][ T365] ------------[ cut here ]------------[ 59.279452][ T365] list_add double add: new=ffff88801d60e350, prev=ffff88801d60e350, next=ffff88801d60e2c0.[ 59.280153][ T365] WARNING: CPU: 3 PID: 365 at lib/list_debug.c:35 __list_add_valid_or_report+0x17f/0x220[ 59.280860][ T365] Modules linked in:[ 59.281165][ T365] CPU: 3 UID: 0 PID: 365 Comm: tc Not tainted 6.18.0-rc7-00105-g7e9f13163c13-dirty #239 PREEMPT(voluntary)[ 59.281977][ T365] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011[ 59.282391][ T365] RIP: 0010:__list_add_valid_or_report+0x17f/0x220[ 59.282842][ T365] Code: 89 c6 e8 d4 b7 0d ff 90 0f 0b 90 90 31 c0 e9 31 ff ff ff 90 48 c7 c7 e0 a0 22 9f 48 89 f2 48 89 c1 4c 89 c6 e8 b2 b7 0d ff 90 <0f> 0b 90 90 31 c0 e9 0f ff ff ff 48 89 f7 48 89 44 24 10 4c 89 44...[ 59.288812][ T365] Call Trace:[ 59.289056][ T365] [ 59.289224][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.289546][ T365] ets_qdisc_change+0xd2b/0x1e80[ 59.289891][ T365] ? __lock_acquire+0x7e7/0x1be0[ 59.290223][ T365] ? __pfx_ets_qdisc_change+0x10/0x10[ 59.290546][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.290898][ T365] ? __mutex_trylock_common+0xda/0x240[ 59.291228][ T365] ? __pfx___mutex_trylock_common+0x10/0x10[ 59.291655][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.291993][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.292313][ T365] ? trace_contention_end+0xc8/0x110[ 59.292656][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.293022][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.293351][ T365] tc_modify_qdisc+0x63a/0x1cf0Fix this by always checking and removing an ets class from the active listwhen changing it to strict.[1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/tree/net/sched/sch_ets.c?id=ce052b9402e461a9aded599f5b47e76bc727f7de#n663
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: fw_tracer, Validate format string parametersAdd validation for format string parameters in the firmware tracer toprevent potential security vulnerabilities and crashes from malformedformat strings received from firmware.The firmware tracer receives format strings from the device firmware anduses them to format trace messages. Without proper validation, badfirmware could provide format strings with invalid format specifiers(e.g., %s, %p, %n) that could lead to crashes, or other undefinedbehavior.Add mlx5_tracer_validate_params() to validate that all format specifiersin trace strings are limited to safe integer/hex formats (%x, %d, %i,%u, %llx, %lx, etc.). Reject strings containing other format types thatcould be used to access arbitrary memory or cause crashes.Invalid format strings are added to the trace output for visibility with"BAD_FORMAT: " prefix.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: alps - fix use-after-free bugs caused by dev3_register_workThe dev3_register_work delayed work item is initialized withinalps_reconnect() and scheduled upon receipt of the first barePS/2 packet from an external PS/2 device connected to the ALPStouchpad. During device detachment, the original implementationcalls flush_workqueue() in psmouse_disconnect() to ensurecompletion of dev3_register_work. However, the flush_workqueue()in psmouse_disconnect() only blocks and waits for work items thatwere already queued to the workqueue prior to its invocation. Anywork items submitted after flush_workqueue() is called are notincluded in the set of tasks that the flush operation awaits.This means that after flush_workqueue() has finished executing,the dev3_register_work could still be scheduled. Although thepsmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(),the scheduling of dev3_register_work remains unaffected.The race condition can occur as follows:CPU 0 (cleanup path) | CPU 1 (delayed work)psmouse_disconnect() | psmouse_set_state() | flush_workqueue() | alps_report_bare_ps2_packet() alps_disconnect() | psmouse_queue_work() kfree(priv); // FREE | alps_register_bare_ps2_mouse() | priv = container_of(work...); // USE | priv->dev3 // USEAdd disable_delayed_work_sync() in alps_disconnect() to ensurethat dev3_register_work is properly canceled and prevented fromexecuting after the alps_data structure has been deallocated.This bug is identified by static analysis.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: using the num_tqps in the vf driver to apply for resourcesCurrently, hdev->htqp is allocated using hdev->num_tqps, and kinfo->tqpis allocated using kinfo->num_tqps. However, kinfo->num_tqps is set tomin(new_tqps, hdev->num_tqps); Therefore, kinfo->num_tqps may be smallerthan hdev->num_tqps, which causes some hdev->htqp[i] to remainuninitialized in hclgevf_knic_setup().Thus, this patch allocates hdev->htqp and kinfo->tqp using hdev->num_tqps,ensuring that the lengths of hdev->htqp and kinfo->tqp are consistentand that all elements are properly initialized.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:svcrdma: bound check rq_pages index in inline pathsvc_rdma_copy_inline_range indexed rqstp->rq_pages[rc_curpage] withoutverifying rc_curpage stays within the allocated page array. Add guardsbefore the first use and after advancing to a new page.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:functionfs: fix the open/removal racesffs_epfile_open() can race with removal, ending up with file->private_datapointing to freed object.There is a total count of opened files on functionfs (both ep0 anddynamic ones) and when it hits zero, dynamic files get removed.Unfortunately, that removal can happen while another thread isin ffs_epfile_open(), but has not incremented the count yet.In that case open will succeed, leaving us with UAF on any subsequentread() or write().The root cause is that ffs->opened is misused; atomic_dec_and_test() vs.atomic_add_return() is not a good idea, when object remains visible allalong.To untangle that * serialize openers on ffs->mutex (both for ep0 and for dynamic files) * have dynamic ones use atomic_inc_not_zero() and fail if we hadzero ->opened; in that case the file we are opening is doomed. * have the inodes of dynamic files marked on removal (from thecallback of simple_recursive_removal()) - clear ->i_private there. * have open of dynamic ones verify they hadn't been already removed,along with checking that state is FFS_ACTIVE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: aic94xx: fix use-after-free in device removal pathThe asd_pci_remove() function fails to synchronize with pending taskletsbefore freeing the asd_ha structure, leading to a potentialuse-after-free vulnerability.When a device removal is triggered (via hot-unplug or module unload),race condition can occur.The fix adds tasklet_kill() before freeing the asd_ha structure,ensuring all scheduled tasklets complete before cleanup proceeds.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: Cap the number of PCR bankstpm2_get_pcr_allocation() does not cap any upper limit for the number ofbanks. Cap the limit to eight banks so that out of bounds values comingfrom external I/O cause on only limited harm.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/64s/slb: Fix SLB multihit issue during SLB preloadOn systems using the hash MMU, there is a software SLB preload cache thatmirrors the entries loaded into the hardware SLB buffer. This preloadcache is subject to periodic eviction - typically after every 256 contextswitches - to remove old entry.To optimize performance, the kernel skips switch_mmu_context() inswitch_mm_irqs_off() when the prev and next mm_struct are the same.However, on hash MMU systems, this can lead to inconsistencies betweenthe hardware SLB and the software preload cache.If an SLB entry for a process is evicted from the software cache on oneCPU, and the same process later runs on another CPU without executingswitch_mmu_context(), the hardware SLB may retain stale entries. If thekernel then attempts to reload that entry, it can trigger an SLBmulti-hit error.The following timeline shows how stale SLB entries are created and cancause a multi-hit error when a process moves between CPUs without aMMU context switch.CPU 0 CPU 1----- -----Process Pexec swapper/1 load_elf_binary begin_new_exc activate_mm switch_mm_irqs_off switch_mmu_context switch_slb /* * This invalidates all * the entries in the HW * and setup the new HW * SLB entries as per the * preload cache. */context_switchsched_migrate_task migrates process P to cpu-1Process swapper/0 context switch (to process P)(uses mm_struct of Process P) switch_mm_irqs_off() switch_slb load_slb++ /* * load_slb becomes 0 here * and we evict an entry from * the preload cache with * preload_age(). We still * keep HW SLB and preload * cache in sync, that is * because all HW SLB entries * anyways gets evicted in * switch_slb during SLBIA. * We then only add those * entries back in HW SLB, * which are currently * present in preload_cache * (after eviction). */ load_elf_binary continues... setup_new_exec() slb_setup_new_exec() sched_switch event sched_migrate_task migrates process P to cpu-0context_switch from swapper/0 to Process P switch_mm_irqs_off() /* * Since both prev and next mm struct are same we don't call * switch_mmu_context(). This will cause the HW SLB and SW preload * cache to go out of sync in preload_new_slb_context. Because there * was an SLB entry which was evicted from both HW and preload cache * on cpu-1. Now later in preload_new_slb_context(), when we will try * to add the same preload entry again, we will add this to the SW * preload cache and then will add it to the HW SLB. Since on cpu-0 * this entry was never invalidated, hence adding this entry to the HW * SLB will cause a SLB multi-hit error. */load_elf_binary cont---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: revert use of devm_kzalloc in btusbThis reverts commit 98921dbd00c4e ("Bluetooth: Use devm_kzalloc inbtusb.c file").In btusb_probe(), we use devm_kzalloc() to allocate the btusb data. Thisties the lifetime of all the btusb data to the binding of a driver toone interface, INTF. In a driver that binds to other interfaces, ISOCand DIAG, this is an accident waiting to happen.The issue is revealed in btusb_disconnect(), where callingusb_driver_release_interface(&btusb_driver, data->intf) will have devmfree the data that is also being used by the other interfaces of thedriver that may not be released yet.To fix this, revert the use of devm and go back to freeing memoryexplicitly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/ttm: Avoid NULL pointer deref for evicted BOsIt is possible for a BO to exist that is not currently associated with aresource, e.g. because it has been evicted.When devcoredump tries to read the contents of all BOs for dumping, we needto expect this as well -- in this case, ENODATA is recorded instead of thebuffer contents.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: fix the crash issue for zero copy XDP_TX actionThere is a crash issue when running zero copy XDP_TX action, the crashlog is shown below.[ 216.122464] Unable to handle kernel paging request at virtual address fffeffff80000000[ 216.187524] Internal error: Oops: 0000000096000144 [#1] SMP[ 216.301694] Call trace:[ 216.304130] dcache_clean_poc+0x20/0x38 (P)[ 216.308308] __dma_sync_single_for_device+0x1bc/0x1e0[ 216.313351] stmmac_xdp_xmit_xdpf+0x354/0x400[ 216.317701] __stmmac_xdp_run_prog+0x164/0x368[ 216.322139] stmmac_napi_poll_rxtx+0xba8/0xf00[ 216.326576] __napi_poll+0x40/0x218[ 216.408054] Kernel panic - not syncing: Oops: Fatal exception in interruptFor XDP_TX action, the xdp_buff is converted to xdp_frame byxdp_convert_buff_to_frame(). The memory type of the resulting xdp_framedepends on the memory type of the xdp_buff. For page pool based xdp_buffit produces xdp_frame with memory type MEM_TYPE_PAGE_POOL. For zero copyXSK pool based xdp_buff it produces xdp_frame with memory typeMEM_TYPE_PAGE_ORDER0. However, stmmac_xdp_xmit_back() does not check thememory type and always uses the page pool type, this leads to invalidmappings and causes the crash. Therefore, check the xdp_buff memory typein stmmac_xdp_xmit_back() to fix this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip6_gre: make ip6gre_header() robustOver the years, syzbot found many ways to crash the kernelin ip6gre_header() [1].This involves team or bonding drivers ability to dynamicallychange their dev->needed_headroom and/or dev->hard_header_lenIn this particular crash mld_newpack() allocated an skbwith a too small reserve/headroom, and by the time mld_sendpack()was called, syzbot managed to attach an ip6gre device.[1]skbuff: skb_under_panic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:213 ! skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 neigh_output include/net/neighbour.h:556 [inline] ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136 __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline] ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: Handle incorrect num_connectors capabilityThe UCSI spec states that the num_connectors field is 7 bits, and the8th bit is reserved and should be set to zero.Some buggy FW has been known to set this bit, and it can lead to asystem not booting.Flag that the FW is not behaving correctly, and auto-fix the valueso that the system boots correctly.Found on Lenovo P1 G8 during Linux enablement program. The FW willbe fixed, but seemed worth addressing in case it hit platforms thataren't officially Linux supported.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Avoid walking the Namespace if start_node is NULLAlthough commit 0c9992315e73 ("ACPICA: Avoid walking the ACPI Namespaceif it is not there") fixed the situation when both start_node andacpi_gbl_root_node are NULL, the Linux kernel mainline now still crashedon Honor Magicbook 14 Pro [1].That happens due to the access to the member of parent_node inacpi_ns_get_next_node(). The NULL pointer dereference will alwayshappen, no matter whether or not the start_node is equal toACPI_ROOT_OBJECT, so move the check of start_node being NULLout of the if block.Unfortunately, all the attempts to contact Honor have failed, theyrefused to provide any technical support for Linux.The bad DSDT table's dump could be found on GitHub [2].DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025[ rjw: Subject adjustment, changelog edits ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbufferInitialize the eb.vma array with values of 0 when the eb structure isfirst set up. In particular, this sets the eb->vma[i].vma pointers toNULL, simplifying cleanup and getting rid of the bug described below.During the execution of eb_lookup_vmas(), the eb->vma array issuccessively filled up with struct eb_vma objects. This process includescalling eb_add_vma(), which might fail; however, even in the event offailure, eb->vma[i].vma is set for the currently processed buffer.If eb_add_vma() fails, eb_lookup_vmas() returns with an error, whichprompts a call to eb_release_vmas() to clean up the mess. Sinceeb_lookup_vmas() might fail during processing any (possibly not first)buffer, eb_release_vmas() checks whether a buffer's vma is NULL to knowat what point did the lookup function fail.In eb_lookup_vmas(), eb->vma[i].vma is set to NULL if either the helperfunction eb_lookup_vma() or eb_validate_vma() fails. eb->vma[i+1].vma isset to NULL in case i915_gem_object_userptr_submit_init() fails; thecurrent one needs to be cleaned up by eb_release_vmas() at this point,so the next one is set. If eb_add_vma() fails, neither the current northe next vma is set to NULL, which is a source of a NULL deref bugdescribed in the issue linked in the Closes tag.When entering eb_lookup_vmas(), the vma pointers are set to the slabpoison value, instead of NULL. This doesn't matter for the actuallookup, since it gets overwritten anyway, however the eb_release_vmas()function only recognizes NULL as the stopping value, hence the pointersare being set to NULL as they go in case of intermediate failure. Thispatch changes the approach to filling them all with NULL at the startinstead, rather than handling that manually during failure.(cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: seqiv - Do not use req->iv after crypto_aead_encryptAs soon as crypto_aead_encrypt is called, the underlying requestmay be freed by an asynchronous completion. Thus dereferencingreq->iv after it returns is invalid.Instead of checking req->iv against info, create a new variableunaligned_info and use it for that purpose instead.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: avoid invalid read in irdma_net_eventirdma_net_event() should not dereference anything from "neigh" (alias"ptr") until it has checked that the event is NETEVENT_NEIGH_UPDATE.Other events come with different structures pointed to by "ptr" and theymay be smaller than struct neighbour.Move the read of neigh->dev under the NETEVENT_NEIGH_UPDATE case.The bug is mostly harmless, but it triggers KASAN on debug kernels: BUG: KASAN: stack-out-of-bounds in irdma_net_event+0x32e/0x3b0 [irdma] Read of size 8 at addr ffffc900075e07f0 by task kworker/27:2/542554 CPU: 27 PID: 542554 Comm: kworker/27:2 Kdump: loaded Not tainted 5.14.0-630.el9.x86_64+debug #1 Hardware name: [...] Workqueue: events rt6_probe_deferred Call Trace: dump_stack_lvl+0x60/0xb0 print_address_description.constprop.0+0x2c/0x3f0 print_report+0xb4/0x270 kasan_report+0x92/0xc0 irdma_net_event+0x32e/0x3b0 [irdma] notifier_call_chain+0x9e/0x180 atomic_notifier_call_chain+0x5c/0x110 rt6_do_redirect+0xb91/0x1080 tcp_v6_err+0xe9b/0x13e0 icmpv6_notify+0x2b2/0x630 ndisc_redirect_rcv+0x328/0x530 icmpv6_rcv+0xc16/0x1360 ip6_protocol_deliver_rcu+0xb84/0x12e0 ip6_input_finish+0x117/0x240 ip6_input+0xc4/0x370 ipv6_rcv+0x420/0x7d0 __netif_receive_skb_one_core+0x118/0x1b0 process_backlog+0xd1/0x5d0 __napi_poll.constprop.0+0xa3/0x440 net_rx_action+0x78a/0xba0 handle_softirqs+0x2d4/0x9c0 do_softirq+0xad/0xe0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: fix "UBSAN: shift-out-of-bounds error"This patch ensures that the RX ring size (rx_pending) is notset below the permitted length. This avoids UBSANshift-out-of-bounds errors when users passes small or zeroring sizes via ethtool -G.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm-verity: disable recursive forward error correctionThere are two problems with the recursive correction:1. It may cause denial-of-service. In fec_read_bufs, there is a loop thathas 253 iterations. For each iteration, we may call verity_hash_for_blockrecursively. There is a limit of 4 nested recursions - that means thatthere may be at most 253^4 (4 billion) iterations. Red Hat QE teamactually created an image that pushes dm-verity to this limit - and thisimage just makes the udev-worker process get stuck in the 'D' state.2. It doesn't work. In fec_read_bufs we store data into the variable"fio->bufs", but fio bufs is shared between recursive invocations, if"verity_hash_for_block" invoked correction recursively, it wouldoverwrite partially filled fio->bufs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: tegra-adma: Fix use-after-freeA use-after-free bug exists in the Tegra ADMA driver when audio streamsare terminated, particularly during XRUN conditions. The issue occurswhen the DMA buffer is freed by tegra_adma_terminate_all() before thevchan completion tasklet finishes accessing it.The race condition follows this sequence: 1. DMA transfer completes, triggering an interrupt that schedules the completion tasklet (tasklet has not executed yet) 2. Audio playback stops, calling tegra_adma_terminate_all() which frees the DMA buffer memory via kfree() 3. The scheduled tasklet finally executes, calling vchan_complete() which attempts to access the already-freed memorySince tasklets can execute at any time after being scheduled, there isno guarantee that the buffer will remain valid when vchan_complete()runs.Fix this by properly synchronizing the virtual channel completion: - Calling vchan_terminate_vdesc() in tegra_adma_stop() to mark the descriptors as terminated instead of freeing the descriptor. - Add the callback tegra_adma_synchronize() that calls vchan_synchronize() which kills any pending tasklets and frees any terminated descriptors.Crash logs:[ 337.427523] BUG: KASAN: use-after-free in vchan_complete+0x124/0x3b0[ 337.427544] Read of size 8 at addr ffff000132055428 by task swapper/0/0[ 337.427562] Call trace:[ 337.427564] dump_backtrace+0x0/0x320[ 337.427571] show_stack+0x20/0x30[ 337.427575] dump_stack_lvl+0x68/0x84[ 337.427584] print_address_description.constprop.0+0x74/0x2b8[ 337.427590] kasan_report+0x1f4/0x210[ 337.427598] __asan_load8+0xa0/0xd0[ 337.427603] vchan_complete+0x124/0x3b0[ 337.427609] tasklet_action_common.constprop.0+0x190/0x1d0[ 337.427617] tasklet_action+0x30/0x40[ 337.427623] __do_softirq+0x1a0/0x5c4[ 337.427628] irq_exit+0x110/0x140[ 337.427633] handle_domain_irq+0xa4/0xe0[ 337.427640] gic_handle_irq+0x64/0x160[ 337.427644] call_on_irq_stack+0x20/0x4c[ 337.427649] do_interrupt_handler+0x7c/0x90[ 337.427654] el1_interrupt+0x30/0x80[ 337.427659] el1h_64_irq_handler+0x18/0x30[ 337.427663] el1h_64_irq+0x7c/0x80[ 337.427667] cpuidle_enter_state+0xe4/0x540[ 337.427674] cpuidle_enter+0x54/0x80[ 337.427679] do_idle+0x2e0/0x380[ 337.427685] cpu_startup_entry+0x2c/0x70[ 337.427690] rest_init+0x114/0x130[ 337.427695] arch_call_rest_init+0x18/0x24[ 337.427702] start_kernel+0x380/0x3b4[ 337.427706] __primary_switched+0xc0/0xc8
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:counter: interrupt-cnt: Drop IRQF_NO_THREAD flagAn IRQ handler can either be IRQF_NO_THREAD or acquire spinlock_t, asCONFIG_PROVE_RAW_LOCK_NESTING warns:=============================[ BUG: Invalid wait context ]6.18.0-rc1+git... #1-----------------------------some-user-space-process/1251 is trying to lock:(&counter->events_list_lock){....}-{3:3}, at: counter_push_event [counter]other info that might help us debug this:context-{2:2}no locks held by some-user-space-process/....stack backtrace:CPU: 0 UID: 0 PID: 1251 Comm: some-user-space-process 6.18.0-rc1+git... #1 PREEMPTCall trace: show_stack (C) dump_stack_lvl dump_stack __lock_acquire lock_acquire _raw_spin_lock_irqsave counter_push_event [counter] interrupt_cnt_isr [interrupt_cnt] __handle_irq_event_percpu handle_irq_event handle_simple_irq handle_irq_desc generic_handle_domain_irq gpio_irq_handler handle_irq_desc generic_handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler el0_interrupt __el0_irq_handler_common el0t_64_irq_handler el0t_64_irq... and Sebastian correctly points out. Remove IRQF_NO_THREAD as analternative to switching to raw_spinlock_t, because the latter would limitall potential nested locks to raw_spinlock_t only.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: always detect conflicting inodes when logging inode refsAfter rename exchanging (either with the rename exchange operation orregular renames in multiple non-atomic steps) two inodes and at leastone of them is a directory, we can end up with a log tree that containsonly of the inodes and after a power failure that can result in an attemptto delete the other inode when it should not because it was not deletedbefore the power failure. In some case that delete attempt fails whenthe target inode is a directory that contains a subvolume inside it, sincethe log replay code is not prepared to deal with directory entries thatpoint to root items (only inode items).1) We have directories "dir1" (inode A) and "dir2" (inode B) under the same parent directory;2) We have a file (inode C) under directory "dir1" (inode A);3) We have a subvolume inside directory "dir2" (inode B);4) All these inodes were persisted in a past transaction and we are currently at transaction N;5) We rename the file (inode C), so at btrfs_log_new_name() we update inode C's last_unlink_trans to N;6) We get a rename exchange for "dir1" (inode A) and "dir2" (inode B), so after the exchange "dir1" is inode B and "dir2" is inode A. During the rename exchange we call btrfs_log_new_name() for inodes A and B, but because they are directories, we don't update their last_unlink_trans to N;7) An fsync against the file (inode C) is done, and because its inode has a last_unlink_trans with a value of N we log its parent directory (inode A) (through btrfs_log_all_parents(), called from btrfs_log_inode_parent()).8) So we end up with inode B not logged, which now has the old name of inode A. At copy_inode_items_to_log(), when logging inode A, we did not check if we had any conflicting inode to log because inode A has a generation lower than the current transaction (created in a past transaction);9) After a power failure, when replaying the log tree, since we find that inode A has a new name that conflicts with the name of inode B in the fs tree, we attempt to delete inode B... this is wrong since that directory was never deleted before the power failure, and because there is a subvolume inside that directory, attempting to delete it will fail since replay_dir_deletes() and btrfs_unlink_inode() are not prepared to deal with dir items that point to roots instead of inodes. When that happens the mount fails and we get a stack trace like the following: [87.2314] BTRFS info (device dm-0): start tree-log replay [87.2318] BTRFS critical (device dm-0): failed to delete reference to subvol, root 5 inode 256 parent 259 [87.2332] ------------[ cut here ]------------ [87.2338] BTRFS: Transaction aborted (error -2) [87.2346] WARNING: CPU: 1 PID: 638968 at fs/btrfs/inode.c:4345 __btrfs_unlink_inode+0x416/0x440 [btrfs] [87.2368] Modules linked in: btrfs loop dm_thin_pool (...) [87.2470] CPU: 1 UID: 0 PID: 638968 Comm: mount Tainted: G W 6.18.0-rc7-btrfs-next-218+ #2 PREEMPT(full) [87.2489] Tainted: [W]=WARN [87.2494] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [87.2514] RIP: 0010:__btrfs_unlink_inode+0x416/0x440 [btrfs] [87.2538] Code: c0 89 04 24 (...) [87.2568] RSP: 0018:ffffc0e741f4b9b8 EFLAGS: 00010286 [87.2574] RAX: 0000000000000000 RBX: ffff9d3ec8a6cf60 RCX: 0000000000000000 [87.2582] RDX: 0000000000000002 RSI: ffffffff84ab45a1 RDI: 00000000ffffffff [87.2591] RBP: ffff9d3ec8a6ef20 R08: 0000000000000000 R09: ffffc0e741f4b840 [87.2599] R10: ffff9d45dc1fffa8 R11: 0000000000000003 R12: ffff9d3ee26d77e0 [87.2608] R13: ffffc0e741f4ba98 R14: ffff9d4458040800 R15: ffff9d44b6b7ca10 [87.2618] FS: 00007f7b9603a840(0000) GS:ffff9d4658982000(0000) knlGS:0000000000000000 [87.---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix NULL dereference on root when tracing inode evictionWhen evicting an inode the first thing we do is to setup tracing for it,which implies fetching the root's id. But in btrfs_evict_inode() theroot might be NULL, as implied in the next check that we do inbtrfs_evict_inode().Hence, we either should set the ->root_objectid to 0 in case the root isNULL, or we move tracing setup after checking that the root is notNULL. Setting the rootid to 0 at least gives us the possibility to tracethis call even in the case when the root is NULL, so that's the solutiontaken here.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: stm32: dmamux: fix device leak on route allocationMake sure to drop the reference taken when looking up the DMA muxplatform device during route allocation.Note that holding a reference to a device does not prevent its driverdata from going away so there is no point in keeping the reference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: ocb: skip rx_no_sta when interface is not joinedieee80211_ocb_rx_no_sta() assumes a valid channel context, which is onlypresent after JOIN_OCB.RX may run before JOIN_OCB is executed, in which case the OCB interfaceis not operational. Skip RX peer handling when the interface is notjoined to avoid warnings in the RX path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: don't WARN for connections on invalid channelsIt's not clear (to me) how exactly syzbot managed to hit this,but it seems conceivable that e.g. regulatory changed and hasdisabled a channel between scanning (channel is checked to beusable by cfg80211_get_ies_channel_number) and connecting onthe channel later.With one scenario that isn't covered elsewhere described above,the warning isn't good, replace it with a (more informative)error message.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Validate sp before freeing associated memorySystem crash with the following signature[154563.214890] nvme nvme2: NVME-FC{1}: controller connect complete[154564.169363] qla2xxx [0000:b0:00.1]-3002:2: nvme: Sched: Set ZIO exchange threshold to 3.[154564.169405] qla2xxx [0000:b0:00.1]-ffffff:2: SET ZIO Activity exchange threshold to 5.[154565.539974] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed - 0078 0080 0000.[154565.545744] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed - 0078 00a0 0000.[154565.545857] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate).[154565.552760] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate).[154565.553079] BUG: kernel NULL pointer dereference, address: 00000000000000f8[154565.553080] #PF: supervisor read access in kernel mode[154565.553082] #PF: error_code(0x0000) - not-present page[154565.553084] PGD 80000010488ab067 P4D 80000010488ab067 PUD 104978a067 PMD 0[154565.553089] Oops: 0000 1 PREEMPT SMP PTI[154565.553092] CPU: 10 PID: 858 Comm: qla2xxx_2_dpc Kdump: loaded Tainted: G OE ------- --- 5.14.0-503.11.1.el9_5.x86_64 #1[154565.553096] Hardware name: HPE Synergy 660 Gen10/Synergy 660 Gen10 Compute Module, BIOS I43 09/30/2024[154565.553097] RIP: 0010:qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx][154565.553141] Code: 00 00 e8 58 a3 ec d4 49 89 e9 ba 12 20 00 00 4c 89 e6 49 c7 c0 00 ee a8 c0 48 c7 c1 66 c0 a9 c0 bf 00 80 00 10 e8 15 69 00 00 <4c> 8b 8d f8 00 00 00 4d 85 c9 74 35 49 8b 84 24 00 19 00 00 48 8b[154565.553143] RSP: 0018:ffffb4dbc8aebdd0 EFLAGS: 00010286[154565.553145] RAX: 0000000000000000 RBX: ffff8ec2cf0908d0 RCX: 0000000000000002[154565.553147] RDX: 0000000000000000 RSI: ffffffffc0a9c896 RDI: ffffb4dbc8aebd47[154565.553148] RBP: 0000000000000000 R08: ffffb4dbc8aebd45 R09: 0000000000ffff0a[154565.553150] R10: 0000000000000000 R11: 000000000000000f R12: ffff8ec2cf0908d0[154565.553151] R13: ffff8ec2cf090900 R14: 0000000000000102 R15: ffff8ec2cf084000[154565.553152] FS: 0000000000000000(0000) GS:ffff8ed27f800000(0000) knlGS:0000000000000000[154565.553154] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[154565.553155] CR2: 00000000000000f8 CR3: 000000113ae0a005 CR4: 00000000007706f0[154565.553157] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[154565.553158] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[154565.553159] PKRU: 55555554[154565.553160] Call Trace:[154565.553162] [154565.553165] ? show_trace_log_lvl+0x1c4/0x2df[154565.553172] ? show_trace_log_lvl+0x1c4/0x2df[154565.553177] ? qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx][154565.553215] ? __die_body.cold+0x8/0xd[154565.553218] ? page_fault_oops+0x134/0x170[154565.553223] ? snprintf+0x49/0x70[154565.553229] ? exc_page_fault+0x62/0x150[154565.553238] ? asm_exc_page_fault+0x22/0x30Check for sp being non NULL before freeing any associated memory
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix reservation leak in some error paths when inserting inline extentIf we fail to allocate a path or join a transaction, we return from__cow_file_range_inline() without freeing the reserved qgroup data,resulting in a leak. Fix this by ensuring we call btrfs_qgroup_free_data()in such cases.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw88: Use devm_kmemdup() in rtw_set_supported_band()Simplify the code by using device managed memory allocations.This also fixes a memory leak in rtw_register_hw(). The supported bandswere not freed in the error path.Copied from commit 145df52a8671 ("wifi: rtw89: Convertrtw89_core_set_supported_band to use devm_*").
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rpmsg: core: fix race in driver_override_show() and use core helperThe driver_override_show function reads the driver_override stringwithout holding the device_lock. However, the store function modifiesand frees the string while holding the device_lock. This creates a racecondition where the string can be freed by the store function whilebeing read by the show function, leading to a use-after-free.To fix this, replace the rpmsg_string_attr macro with explicit show andstore functions. The new driver_override_store uses the standarddriver_set_override helper. Since the introduction ofdriver_set_override, the comments in include/linux/rpmsg.h have statedthat this helper must be used to set or clear driver_override, but theimplementation was not updated until now.Because driver_set_override modifies and frees the string while holdingthe device_lock, the new driver_override_show now correctly holds thedevice_lock during the read operation to prevent the race.Additionally, since rpmsg_string_attr has only ever been used fordriver_override, removing the macro simplifies the code.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: qrtr: Drop the MHI auto_queue feature for IPCR DL channelsMHI stack offers the 'auto_queue' feature, which allows the MHI stack toauto queue the buffers for the RX path (DL channel). Though this featuresimplifies the client driver design, it introduces race between the clientdrivers and the MHI stack. For instance, with auto_queue, the 'dl_callback'for the DL channel may get called before the client driver is fully probed.This means, by the time the dl_callback gets called, the client driver'sstructures might not be initialized, leading to NULL ptr dereference.Currently, the drivers have to workaround this issue by initializing theinternal structures before calling mhi_prepare_for_transfer_autoqueue().But even so, there is a chance that the client driver's internal code pathmay call the MHI queue APIs before mhi_prepare_for_transfer_autoqueue() iscalled, leading to similar NULL ptr dereference. This issue has beenreported on the Qcom X1E80100 CRD machines affecting boot.So to properly fix all these races, drop the MHI 'auto_queue' featurealtogether and let the client driver (QRTR) manage the RX buffers manually.In the QRTR driver, queue the RX buffers based on the ring length duringprobe and recycle the buffers in 'dl_callback' once they are consumed. Thisalso warrants removing the setting of 'auto_queue' flag from controllerdrivers.Currently, this 'auto_queue' feature is only enabled for IPCR DL channel.So only the QRTR client driver requires the modification.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw88: 8822b: Avoid WARNING in rtw8822b_config_trx_mode()rtw8822b_set_antenna() can be called from userspace when the chip ispowered off. In that case a WARNING is triggered inrtw8822b_config_trx_mode() because trying to read the RF registerswhen the chip is powered off returns an unexpected value.Call rtw8822b_config_trx_mode() in rtw8822b_set_antenna() only whenthe chip is powered on.------------[ cut here ]------------write RF mode table failWARNING: CPU: 0 PID: 7183 at rtw8822b.c:824 rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b]CPU: 0 UID: 0 PID: 7183 Comm: iw Tainted: G W OE 6.17.5-arch1-1 #1 PREEMPT(full) 01c39fc421df2af799dd5e9180b572af860b40c1Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULEHardware name: LENOVO 82KR/LNVNB161216, BIOS HBCN18WW 08/27/2021RIP: 0010:rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b]Call Trace: rtw8822b_set_antenna+0x57/0x70 [rtw88_8822b 370206f42e5890d8d5f48eb358b759efa37c422b] rtw_ops_set_antenna+0x50/0x80 [rtw88_core 711c8fb4f686162be4625b1d0b8e8c6a5ac850fb] ieee80211_set_antenna+0x60/0x100 [mac80211 f1845d85d2ecacf3b71867635a050ece90486cf3] nl80211_set_wiphy+0x384/0xe00 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? netdev_run_todo+0x63/0x550 genl_family_rcv_msg_doit+0xfc/0x160 genl_rcv_msg+0x1aa/0x2b0 ? __pfx_nl80211_pre_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? __pfx_nl80211_set_wiphy+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? __pfx_nl80211_post_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x59/0x110 genl_rcv+0x28/0x40 netlink_unicast+0x285/0x3c0 ? __alloc_skb+0xdb/0x1a0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x39f/0x3d0 ? import_iovec+0x2f/0x40 ___sys_sendmsg+0x99/0xe0 ? refill_obj_stock+0x12e/0x240 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x81/0x970 ? do_syscall_64+0x81/0x970 ? ksys_read+0x73/0xf0 ? do_syscall_64+0x81/0x970 ? count_memcg_events+0xc2/0x190 ? handle_mm_fault+0x1d7/0x2d0 ? do_user_addr_fault+0x21a/0x690 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: Fix NULL deref when deactivating inactive aggregate in qfq_reset`qfq_class->leaf_qdisc->q.qlen > 0` does not imply that the classitself is active.Two qfq_class objects may point to the same leaf_qdisc. This happenswhen:1. one QFQ qdisc is attached to the dev as the root qdisc, and2. another QFQ qdisc is temporarily referenced (e.g., via qdisc_get()/ qdisc_put()) and is pending to be destroyed, as in functiontc_new_tfilter.When packets are enqueued through the root QFQ qdisc, the sharedleaf_qdisc->q.qlen increases. At the same time, the second QFQqdisc triggers qdisc_put and qdisc_destroy: the qdisc entersqfq_reset() with its own q->q.qlen == 0, but its class's leafqdisc->q.qlen > 0. Therefore, the qfq_reset would wrongly deactivatean inactive aggregate and trigger a null-deref in qfq_deactivate_agg:[ 0.903172] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 0.903571] #PF: supervisor write access in kernel mode[ 0.903860] #PF: error_code(0x0002) - not-present page[ 0.904177] PGD 10299b067 P4D 10299b067 PUD 10299c067 PMD 0[ 0.904502] Oops: Oops: 0002 [#1] SMP NOPTI[ 0.904737] CPU: 0 UID: 0 PID: 135 Comm: exploit Not tainted 6.19.0-rc3+ #2 NONE[ 0.905157] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014[ 0.905754] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:992 (discriminator 2) include/linux/list.h:1006 (discriminator 2) net/sched/sch_qfq.c:1367 (discriminator 2) net/sched/sch_qfq.c:1393 (discriminator 2))[ 0.906046] Code: 0f 84 4d 01 00 00 48 89 70 18 8b 4b 10 48 c7 c2 ff ff ff ff 48 8b 78 08 48 d3 e2 48 21 f2 48 2b 13 48 8b 30 48 d3 ea 8b 4b 18 0Code starting with the faulting instruction=========================================== 0: 0f 84 4d 01 00 00 je 0x153 6: 48 89 70 18 mov %rsi,0x18(%rax) a: 8b 4b 10 mov 0x10(%rbx),%ecx d: 48 c7 c2 ff ff ff ff mov $0xffffffffffffffff,%rdx 14: 48 8b 78 08 mov 0x8(%rax),%rdi 18: 48 d3 e2 shl %cl,%rdx 1b: 48 21 f2 and %rsi,%rdx 1e: 48 2b 13 sub (%rbx),%rdx 21: 48 8b 30 mov (%rax),%rsi 24: 48 d3 ea shr %cl,%rdx 27: 8b 4b 18 mov 0x18(%rbx),%ecx ...[ 0.907095] RSP: 0018:ffffc900004a39a0 EFLAGS: 00010246[ 0.907368] RAX: ffff8881043a0880 RBX: ffff888102953340 RCX: 0000000000000000[ 0.907723] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000[ 0.908100] RBP: ffff888102952180 R08: 0000000000000000 R09: 0000000000000000[ 0.908451] R10: ffff8881043a0000 R11: 0000000000000000 R12: ffff888102952000[ 0.908804] R13: ffff888102952180 R14: ffff8881043a0ad8 R15: ffff8881043a0880[ 0.909179] FS: 000000002a1a0380(0000) GS:ffff888196d8d000(0000) knlGS:0000000000000000[ 0.909572] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 0.909857] CR2: 0000000000000000 CR3: 0000000102993002 CR4: 0000000000772ef0[ 0.910247] PKRU: 55555554[ 0.910391] Call Trace:[ 0.910527] [ 0.910638] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1485)[ 0.910826] qdisc_reset (include/linux/skbuff.h:2195 include/linux/skbuff.h:2501 include/linux/skbuff.h:3424 include/linux/skbuff.h:3430 net/sched/sch_generic.c:1036)[ 0.911040] __qdisc_destroy (net/sched/sch_generic.c:1076)[ 0.911236] tc_new_tfilter (net/sched/cls_api.c:2447)[ 0.911447] rtnetlink_rcv_msg (net/core/rtnetlink.c:6958)[ 0.911663] ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:6861)[ 0.911894] netlink_rcv_skb (net/netlink/af_netlink.c:2550)[ 0.912100] netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)[ 0.912296] ? __alloc_skb (net/core/skbuff.c:706)[ 0.912484] netlink_sendmsg (net/netlink/af---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mscc: ocelot: Fix crash when adding interface under a lagCommit 15faa1f67ab4 ("lan966x: Fix crash when adding interface under a lag")fixed a similar issue in the lan966x driver caused by a NULL pointer dereference.The ocelot_set_aggr_pgids() function in the ocelot driver has similar logicand is susceptible to the same crash.This issue specifically affects the ocelot_vsc7514.c frontend, which leavesunused ports as NULL pointers. The felix_vsc9959.c frontend is unaffected asit uses the DSA framework which registers all ports.Fix this by checking if the port pointer is valid before accessing it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: check that server is running in unlock_filesystemIf we are trying to unlock the filesystem via an administrativeinterface and nfsd isn't running, it crashes the server. Thishappens currently because nfsd4_revoke_states() access statestructures (eg., conf_id_hashtbl) that has been freed as a partof the server shutdown.[ 59.465072] Call trace:[ 59.465308] nfsd4_revoke_states+0x1b4/0x898 [nfsd] (P)[ 59.465830] write_unlock_fs+0x258/0x440 [nfsd][ 59.466278] nfsctl_transaction_write+0xb0/0x120 [nfsd][ 59.466780] vfs_write+0x1f0/0x938[ 59.467088] ksys_write+0xfc/0x1f8[ 59.467395] __arm64_sys_write+0x74/0xb8[ 59.467746] invoke_syscall.constprop.0+0xdc/0x1e8[ 59.468177] do_el0_svc+0x154/0x1d8[ 59.468489] el0_svc+0x40/0xe0[ 59.468767] el0t_64_sync_handler+0xa0/0xe8[ 59.469138] el0t_64_sync+0x1ac/0x1b0Ensure this can't happen by taking the nfsd_mutex and checking thatthe server is still up, and then holding the mutex across the call tonfsd4_revoke_states().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: make free_choose_arg_map() resilient to partial allocationfree_choose_arg_map() may dereference a NULL pointer if its caller failsafter a partial allocation.For example, in decode_choose_args(), if allocation of arg_map->argsfails, execution jumps to the fail label and free_choose_arg_map() iscalled. Since arg_map->size is updated to a non-zero value before memoryallocation, free_choose_arg_map() will iterate over arg_map->args anddereference a NULL pointer.To prevent this potential NULL pointer dereference and makefree_choose_arg_map() more resilient, add checks for pointers beforeiterating.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix reference count leak in bpf_prog_test_run_xdp()syzbot is reporting unregister_netdevice: waiting for sit0 to become free. Usage count = 2problem. A debug printk() patch found that a refcount is obtained atxdp_convert_md_to_buff() from bpf_prog_test_run_xdp().According to commit ec94670fcb3b ("bpf: Support specifying ingress viaxdp_md context in BPF_PROG_TEST_RUN"), the refcount obtained byxdp_convert_md_to_buff() will be released by xdp_convert_buff_to_md().Therefore, we can consider that the error handling path introduced bycommit 1c1949982524 ("bpf: introduce frags support tobpf_prog_test_run_xdp()") forgot to call xdp_convert_buff_to_md().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Don't store mlx5e_priv in mlx5e_dev devlink privmlx5e_priv is an unstable structure that can be memset(0) if profileattaching fails, mlx5e_priv in mlx5e_dev devlink private is used toreference the netdev and mdev associated with that struct. Instead,store netdev directly into mlx5e_dev and get mdev from the containingmlx5_adev aux device structure.This fixes a kernel oops in mlx5e_remove when switchdev mode fails dueto change profile failure.$ devlink dev eswitch set pci/0000:00:03.0 mode switchdevError: mlx5_core: Failed setting eswitch to offloads.dmesg:workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTRmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTRmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12$ devlink dev reload pci/0000:00:03.0 ==> oopsBUG: kernel NULL pointer dereference, address: 0000000000000520 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present pagePGD 0 P4D 0Oops: Oops: 0000 [#1] SMP NOPTICPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014RIP: 0010:mlx5e_remove+0x68/0x130RSP: 0018:ffffc900034838f0 EFLAGS: 00010246RAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000RBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10R10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0R13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400FS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0Call Trace: device_release_driver_internal+0x19c/0x200 bus_remove_device+0xc6/0x130 device_del+0x160/0x3d0 ? devl_param_driverinit_value_get+0x2d/0x90 mlx5_detach_device+0x89/0xe0 mlx5_unload_one_devl_locked+0x3a/0x70 mlx5_devlink_reload_down+0xc8/0x220 devlink_reload+0x7d/0x260 devlink_nl_reload_doit+0x45b/0x5a0 genl_family_rcv_msg_doit+0xe8/0x140
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rtsSince j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() iscalled only when the timer is enabled, we need to callj1939_session_deactivate_activate_next() if we cancelled the timer.Otherwise, refcount for j1939_session leaks, which will later appear as| unregister_netdevice: waiting for vcan0 to become free. Usage count = 2.problem.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovecCommit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length")added ttag bounds checking and data_offsetvalidation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validatewhether the command's data structures (cmd->req.sg and cmd->iov) havebeen properly initialized before processing H2C_DATA PDUs.The nvmet_tcp_build_pdu_iovec() function dereferences these pointerswithout NULL checks. This can be triggered by sending H2C_DATA PDUimmediately after the ICREQ/ICRESP handshake, beforesending a CONNECT command or NVMe write command.Attack vectors that trigger NULL pointer dereferences:1. H2C_DATA PDU sent before CONNECT -> both pointers NULL2. H2C_DATA PDU for READ command -> cmd->req.sg allocated, cmd->iov NULL3. H2C_DATA PDU for uninitialized command slot -> both pointers NULLThe fix validates both cmd->req.sg and cmd->iov before callingnvmet_tcp_build_pdu_iovec(). Both checks are required because:- Uninitialized commands: both NULL- READ commands: cmd->req.sg allocated, cmd->iov NULL- WRITE commands: both allocated
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix crash on profile change rollback failuremlx5e_netdev_change_profile can fail to attach a new profile and canfail to rollback to old profile, in such case, we could end up with adangling netdev with a fully reset netdev_priv. A retry to changeprofile, e.g. another attempt to call mlx5e_netdev_change_profile viaswitchdev mode change, will crash trying to access the now NULLpriv->mdev.This fix allows mlx5e_netdev_change_profile() to handle previousfailures and an empty priv, by not assuming priv is valid.Pass netdev and mdev to all flows requiringmlx5e_netdev_change_profile() and avoid passing priv.In mlx5e_netdev_change_profile() check if current priv is valid, and ifnot, just attach the new profile without trying to access the old one.This fixes the following oops, when enabling switchdev mode for the 2ndtime after first time failure: ## Enabling switchdev mode first time:mlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offloadworkqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTRmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTRmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12 ^^^^^^^^mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0) ## retry: Enabling switchdev mode 2nd time:mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offloadBUG: kernel NULL pointer dereference, address: 0000000000000038 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present pagePGD 0 P4D 0Oops: Oops: 0000 [#1] SMP NOPTICPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014RIP: 0010:mlx5e_detach_netdev+0x3c/0x90Code: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 <48> 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07RSP: 0018:ffffc90000673890 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000RDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000RBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000R10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000R13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000FS: 00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0Call Trace: mlx5e_netdev_change_profile+0x45/0xb0 mlx5e_vport_rep_load+0x27b/0x2d0 mlx5_esw_offloads_rep_load+0x72/0xf0 esw_offloads_enable+0x5d0/0x970 mlx5_eswitch_enable_locked+0x349/0x430 ? is_mp_supported+0x57/0xb0 mlx5_devlink_eswitch_mode_set+0x26b/0x430 devlink_nl_eswitch_set_doit+0x6f/0xf0 genl_family_rcv_msg_doit+0xe8/0x140 genl_rcv_msg+0x18b/0x290 ? __pfx_devlink_nl_pre_doit+0x10/0x10 ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10 ? __pfx_devlink_nl_post_doit+0x10/0x10 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x52/0x100 genl_rcv+0x28/0x40 netlink_unicast+0x282/0x3e0 ? __alloc_skb+0xd6/0x190 netlink_sendmsg+0x1f7/0x430 __sys_sendto+0x213/0x220 ? __sys_recvmsg+0x6a/0xd0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7fdfb8495047
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: ip_gre: make ipgre_header() robustAnalog to commit db5b4e39c4e6 ("ip6_gre: make ip6gre_header() robust")Over the years, syzbot found many ways to crash the kernelin ipgre_header() [1].This involves team or bonding drivers ability to dynamicallychange their dev->needed_headroom and/or dev->hard_header_lenIn this particular crash mld_newpack() allocated an skbwith a too small reserve/headroom, and by the time mld_sendpack()was called, syzbot managed to attach an ipgre device.[1]skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0 kernel BUG at net/core/skbuff.c:213 !Oops: invalid opcode: 0000 [#1] SMP KASAN PTICPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025Workqueue: mld mld_ifc_work RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213Call Trace: skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix error handling in the init_task on loadIf the init_task fails during a driver load, we end up without vports andnetdevs, effectively failing the entire process. In that state asubsequent reset will result in a crash as the service task attempts toaccess uninitialized resources. Following trace is from an error in theinit_task where the CREATE_VPORT (op 501) is rejected by the FW:[40922.763136] idpf 0000:83:00.0: Device HW Reset initiated[40924.449797] idpf 0000:83:00.0: Transaction failed (op 501)[40958.148190] idpf 0000:83:00.0: HW reset detected[40958.161202] BUG: kernel NULL pointer dereference, address: 00000000000000a8...[40958.168094] Workqueue: idpf-0000:83:00.0-vc_event idpf_vc_event_task [idpf][40958.168865] RIP: 0010:idpf_vc_event_task+0x9b/0x350 [idpf]...[40958.177932] Call Trace:[40958.178491] [40958.179040] process_one_work+0x226/0x6d0[40958.179609] worker_thread+0x19e/0x340[40958.180158] ? __pfx_worker_thread+0x10/0x10[40958.180702] kthread+0x10f/0x250[40958.181238] ? __pfx_kthread+0x10/0x10[40958.181774] ret_from_fork+0x251/0x2b0[40958.182307] ? __pfx_kthread+0x10/0x10[40958.182834] ret_from_fork_asm+0x1a/0x30[40958.183370] Fix the error handling in the init_task to make sure the service andmailbox tasks are disabled if the error happens during load. These arestarted in idpf_vc_core_init(), which spawns the init_task and has no wayof knowing if it failed. If the error happens on reset, followingsuccessful driver load, the tasks can still run, as that will allow thenetdevs to attempt recovery through another reset. Stop the PTP callbackseither way as those will be restarted by the call to idpf_vc_core_init()during a successful reset.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: 3com: 3c59x: fix possible null dereference in vortex_probe1()pdev can be null and free_ring: can be called in 1297 with a nullpdev.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of privmlx5e_priv is an unstable structure that can be memset(0) if profileattaching fails.Pass netdev to mlx5e_destroy_netdev() to guarantee it will work on avalid netdev.On mlx5e_remove: Check validity of priv->profile, before attemptingto cleanup any resources that might be not there.This fixes a kernel oops in mlx5e_remove when switchdev mode fails dueto change profile failure.$ devlink dev eswitch set pci/0000:00:03.0 mode switchdevError: mlx5_core: Failed setting eswitch to offloads.dmesg:workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTRmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTRmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12$ devlink dev reload pci/0000:00:03.0 ==> oopsBUG: kernel NULL pointer dereference, address: 0000000000000370PGD 0 P4D 0Oops: Oops: 0000 [#1] SMP NOPTICPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014RIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100RSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286RAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0RBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10R10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0R13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400FS: 00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0Call Trace: mlx5e_remove+0x57/0x110 device_release_driver_internal+0x19c/0x200 bus_remove_device+0xc6/0x130 device_del+0x160/0x3d0 ? devl_param_driverinit_value_get+0x2d/0x90 mlx5_detach_device+0x89/0xe0 mlx5_unload_one_devl_locked+0x3a/0x70 mlx5_devlink_reload_down+0xc8/0x220 devlink_reload+0x7d/0x260 devlink_nl_reload_doit+0x45b/0x5a0 genl_family_rcv_msg_doit+0xe8/0x140
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uacce: ensure safe queue release with state managementDirectly calling `put_queue` carries risks since it cannotguarantee that resources of `uacce_queue` have been fully releasedbeforehand. So adding a `stop_queue` operation for theUACCE_CMD_PUT_Q command and leaving the `put_queue` operation tothe final resource release ensures safety.Queue states are defined as follows:- UACCE_Q_ZOMBIE: Initial state- UACCE_Q_INIT: After opening `uacce`- UACCE_Q_STARTED: After `start` is issued via `ioctl`When executing `poweroff -f` in virt while accelerator are stillworking, `uacce_fops_release` and `uacce_remove` may executeconcurrently. This can cause `uacce_put_queue` within`uacce_fops_release` to access a NULL `ops` pointer. Therefore, addstate checks to prevent accessing freed pointers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regmap: Fix race condition in hwspinlock irqsave routinePreviously, the address of the shared member '&map->spinlock_flags' waspassed directly to 'hwspin_lock_timeout_irqsave'. This creates a racecondition where multiple contexts contending for the lock could overwritethe shared flags variable, potentially corrupting the state for thecurrent lock owner.Fix this by using a local stack variable 'flags' to store the IRQ statetemporarily.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v3-its: Avoid truncating memory addressesOn 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmemallocations to be backed by addresses physical memory above the 32-bitaddress limit, as found while experimenting with larger VMSPLITconfigurations.This caused the qemu virt model to crash in the GICv3 driver, whichallocates the 'itt' object using GFP_KERNEL. Since all memory belowthe 4GB physical address limit is in ZONE_DMA in this configuration,kmalloc() defaults to higher addresses for ZONE_NORMAL, and theITS driver stores the physical address in a 32-bit 'unsigned long'variable.Change the itt_addr variable to the correct phys_addr_t type instead,along with all other variables in this driver that hold a physicaladdress.The gicv5 driver correctly uses u64 variables, while all other irqchipdrivers don't call virt_to_phys or similar interfaces. It's expected thatother device drivers have similar issues, but fixing this one issufficient for booting a virtio based guest.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:slimbus: core: fix device reference leak on report presentSlimbus devices can be allocated dynamically upon reception ofreport-present messages.Make sure to drop the reference taken when looking up already registereddevices.Note that this requires taking an extra reference in case the device hasnot yet been registered and has to be allocated.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gue: Fix skb memleak with inner IP protocol 0.syzbot reported skb memleak below. [0]The repro generated a GUE packet with its inner protocol 0.gue_udp_recv() returns -guehdr->proto_ctype for "resubmit"in ip_protocol_deliver_rcu(), but this only works withnon-zero protocol number.Let's drop such packets.Note that 0 is a valid number (IPv6 Hop-by-Hop Option).I think it is not practical to encap HOPOPT in GUE, so oncesomeone starts to complain, we could pass down a resubmitflag pointer to distinguish two zeros from the upper layer: * no error * resubmit HOPOPT[0]BUG: memory leakunreferenced object 0xffff888109695a00 (size 240): comm "syz.0.17", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4958 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270 __build_skb+0x23/0x60 net/core/skbuff.c:474 build_skb+0x20/0x190 net/core/skbuff.c:490 __tun_build_skb drivers/net/tun.c:1541 [inline] tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636 tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770 tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0xa7/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uacce: fix cdev handling in the cleanup pathWhen cdev_device_add fails, it internally releases the cdev memory,and if cdev_device_del is then executed, it will cause a hang error.To fix it, we check the return value of cdev_device_add() and clearuacce->cdev to avoid calling cdev_device_del in the uacce_remove.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:migrate: correct lock ordering for hugetlb file foliosSyzbot has found a deadlock (analyzed by Lance Yang):1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock).2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquirefolio_lock.migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- Takes folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)!hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- Waits for folio_lock!The migration path is the one taking locks in the wrong order according tothe documentation at the top of mm/rmap.c. So expand the scope of theexisting i_mmap_lock to cover the calls to remove_migration_ptes() too.This is (mostly) how it used to be after commit c0d0381ade79. That wasremoved by 336bf30eb765 for both file & anon hugetlb pages when it shouldonly have been removed for anon hugetlb pages.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: limit BOND_MODE_8023AD to Ethernet devicesBOND_MODE_8023AD makes sense for ARPHRD_ETHER only.syzbot reported: BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline] BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full)Tainted: [L]=SOFTLOCKUPHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 __hw_addr_create net/core/dev_addr_lists.c:63 [inline] __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 __dev_mc_add net/core/dev_addr_lists.c:868 [inline] dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886 bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180 do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963 do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165 rtnl_changelink net/core/rtnetlink.c:3776 [inline] __rtnl_newlink net/core/rtnetlink.c:3935 [inline] rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 ____sys_sendmsg+0x505/0x820 net/socket.c:2592 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646 __sys_sendmsg+0x164/0x220 net/socket.c:2678 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307 do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332 entry_SYSENTER_compat_after_hwframe+0x84/0x8e The buggy address belongs to the variable: lacpdu_mcast_addr+0x0/0x40
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:leds: led-class: Only Add LED to leds_list when it is fully readyBefore this change the LED was added to leds_list before led_init_core()gets called adding it the list before led_classdev.set_brightness_work getsinitialized.This leaves a window where led_trigger_register() of a LED's defaulttrigger will call led_trigger_set() which calls led_set_brightness()which in turn will end up queueing the *uninitialized*led_classdev.set_brightness_work.This race gets hit by the lenovo-thinkpad-t14s EC driver which registers2 LEDs with a default trigger provided by snd_ctl_led.ko in quicksuccession. The first led_classdev_register() causes an async modprobe ofsnd_ctl_led to run and that async modprobe manages to exactly hitthe window where the second LED is on the leds_list without led_init_core()being called for it, resulting in: ------------[ cut here ]------------ WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390 Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025 ... Call trace: __flush_work+0x344/0x390 (P) flush_work+0x2c/0x50 led_trigger_set+0x1c8/0x340 led_trigger_register+0x17c/0x1c0 led_trigger_register_simple+0x84/0xe8 snd_ctl_led_init+0x40/0xf88 [snd_ctl_led] do_one_initcall+0x5c/0x318 do_init_module+0x9c/0x2b8 load_module+0x7e0/0x998Close the race window by moving the adding of the LED to leds_list toafter the led_init_core() call.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loopCurrently this is checked before running the pending work. Normally thisis quite fine, as work items either end up blocking (which will create anew worker for other items), or they complete fairly quickly. But syzbotreports an issue where io-wq takes seemingly forever to exit, and with abit of debugging, this turns out to be because it queues a bunch of big(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn'tsupport ->read_iter(), loop_rw_iter() ends up handling them. Each readreturns 16MB of data read, which takes 20 (!!) seconds. With a bunch ofthese pending, processing the whole chain can take a long time. Easilylonger than the syzbot uninterruptible sleep timeout of 140 seconds.This then triggers a complaint off the io-wq exit path:INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump."echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000Call Trace: context_switch kernel/sched/core.c:5256 [inline] __schedule+0x1139/0x6150 kernel/sched/core.c:6863 __schedule_loop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75 do_wait_for_common kernel/sched/completion.c:100 [inline] __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121 io_wq_exit_workers io_uring/io-wq.c:1328 [inline] io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356 io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203 io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651 io_uring_files_cancel include/linux/io_uring.h:19 [inline] do_exit+0x2ce/0x2bd0 kernel/exit.c:911 do_group_exit+0xd3/0x2a0 kernel/exit.c:1112 get_signal+0x2671/0x26d0 kernel/signal.c:3034 arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 __exit_to_user_mode_loop kernel/entry/common.c:41 [inline] exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fa02738f749RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000caRAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98There's really nothing wrong here, outside of processing these readswill take a LONG time. However, we can speed up the exit by checking theIO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot willexit the ring after queueing up all of these reads. Then once the firstitem is processed, io-wq will simply cancel the rest. That should avoidsyzbot running into this complaint again.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix data-race warning and potential load/store tearingFix the following: BUG: KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packetwhich is reporting an issue with the reads and writes to ->last_tx_at in: conn->peer->last_tx_at = ktime_get_seconds();and: keepalive_at = peer->last_tx_at + RXRPC_KEEPALIVE_TIME;The lockless accesses to these to values aren't actually a problem as theread only needs an approximate time of last transmission for the purposesof deciding whether or not the transmission of a keepalive packet iswarranted yet.Also, as ->last_tx_at is a 64-bit value, tearing can occur on a 32-bitarch.Fix both of these by switching to an unsigned int for ->last_tx_at and onlystoring the LSW of the time64_t. It can then be reconstructed at needprovided no more than 68 years has elapsed since the last transmission.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: provide a net pointer to __skb_flow_dissect()After 3cbf4ffba5ee ("net: plumb network namespace into __skb_flow_dissect")we have to provide a net pointer to __skb_flow_dissect(),either via skb->dev, skb->sk, or a user provided pointer.In the following case, syzbot was able to cook a bare skb.WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053Call Trace: bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline] __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157 bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline] bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline] bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515 xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388 bpf_prog_run_xdp include/net/xdp.h:700 [inline] bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421 bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390 bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703 __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182 __do_sys_bpf kernel/bpf/syscall.c:6274 [inline] __se_sys_bpf kernel/bpf/syscall.c:6272 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: avoid one data-race in l2tp_tunnel_del_work()We should read sk->sk_socket only when dealing with kernel sockets.syzbot reported the following data-race:BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_releasewrite to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sk_set_socket include/net/sock.h:2092 [inline] sock_orphan include/net/sock.h:2118 [inline] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [inline] sock_close+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 ____fput+0x1c/0x30 fs/file_table.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:44 [inline] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7fread to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 worker_thread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246value changed: 0xffff88811b818000 -> 0x0000000000000000
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INITA null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH keyinitialization fails: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2 RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline] RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401 Call Trace: sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189 sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052 sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88 sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127The issue is triggered when sctp_auth_asoc_init_active_key() fails insctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, thecommand sequence is currently:- SCTP_CMD_PEER_INIT- SCTP_CMD_TIMER_STOP (T1_INIT)- SCTP_CMD_TIMER_START (T1_COOKIE)- SCTP_CMD_NEW_STATE (COOKIE_ECHOED)- SCTP_CMD_ASSOC_SHKEY- SCTP_CMD_GEN_COOKIE_ECHOIf SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, whileasoc->peer.auth_capable and asoc->peer.peer_chunks have already been set bySCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULLto be queued by sctp_datamsg_from_user().Since command interpretation stops on failure, no COOKIE_ECHO should beensent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has alreadybeen started, and it may enqueue a COOKIE_ECHO into the outqueue later. Asa result, the DATA chunk can be transmitted together with the COOKIE_ECHOin sctp_outq_flush_data(), leading to the observed issue.Similar to the other places where it calls sctp_auth_asoc_init_active_key()right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEYimmediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and startingT1_COOKIE. This ensures that if shared key generation fails, authenticatedDATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT,giving the client another chance to process INIT_ACK and retry key setup.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: reset sparse-read state in osd_fault()When a fault occurs, the connection is abandoned, reestablished, and anypending operations are retried. The OSD client tracks the progress of asparse-read reply using a separate state machine, largely independent ofthe messenger's state.If a connection is lost mid-payload or the sparse-read state machinereturns an error, the sparse-read state is not reset. The OSD clientwill then interpret the beginning of a new reply as the continuation ofthe old one. If this makes the sparse-read machinery enter a failurestate, it may never recover, producing loops like: libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on readTherefore, reset the sparse-read state in osd_fault(), ensuring retriesstart from a clean state.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Add recursion protection in kernel stack trace recordingA bug was reported about an infinite recursion caused by tracing the rcuevents with the kernel stack trace trigger enabled. The stack trace codecalled back into RCU which then called the stack trace again.Expand the ftrace recursion protection to add a set of bits to protectevents from recursion. Each bit represents the context that the event isin (normal, softirq, interrupt and NMI).Have the stack trace code use the interrupt context to protect againstrecursion.Note, the bug showed an issue in both the RCU code as well as the tracingstacktrace code. This only handles the tracing stack trace side of thebug. The RCU fix will be handled separately.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, test_run: Subtract size of xdp_frame from allowed metadata sizeThe xdp_frame structure takes up part of the XDP frame headroom,limiting the size of the metadata. However, in bpf_test_run, we don'ttake this into account, which makes it possible for userspace to supplya metadata size that is too large (taking up the entire headroom).If userspace supplies such a large metadata size in live packet mode,the xdp_update_frame_from_buff() call in xdp_test_run_init_page() callwill fail, after which packet transmission proceeds with anuninitialised frame structure, leading to the usual Bad Stuff.The commit in the Fixes tag fixed a related bug where the second checkin xdp_update_frame_from_buff() could fail, but did not add anyadditional constraints on the metadata size. Complete the fix by addingan additional check on the metadata size. Reorder the checks slightly tomake the logic clearer and add a comment.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: send: check for inline extents in range_is_hole_in_parent()Before accessing the disk_bytenr field of a file extent item we needto check if we are dealing with an inline extent.This is because for inline extents their data starts at the offset ofthe disk_bytenr field. So accessing the disk_bytenrmeans we are accessing inline data or in case the inline data is lessthan 8 bytes we can actually cause an invalidmemory access if this inline extent item is the first item in the leafor access metadata from other items.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Fix memory leak in set_ssp_completeFix memory leak in set_ssp_complete() where mgmt_pending_cmd structuresare not freed after being removed from the pending list.Commit 302a1f674c00 ("Bluetooth: MGMT: Fix possible UAFs") replacedmgmt_pending_foreach() calls with individual command handling but missedadding mgmt_pending_free() calls in both error and success paths ofset_ssp_complete(). Other completion functions like set_le_complete()were fixed correctly in the same commit.This causes a memory leak of the mgmt_pending_cmd structure and itsassociated parameter data for each SSP command that completes.Add the missing mgmt_pending_free(cmd) calls in both code paths to fixthe memory leak. Also fix the same issue in set_advertising_complete().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix segmentation of forwarding fraglist GROThis patch enhances GSO segment handling by properly checkingthe SKB_GSO_DODGY flag for frag_list GSO packets, addressinglow throughput issues observed when a station accesses IPv4servers via hotspots with an IPv6-only upstream interface.Specifically, it fixes a bug in GSO segmentation when forwardingGRO packets containing a frag_list. The function skb_segment_listcannot correctly process GRO skbs that have been converted by XLAT,since XLAT only translates the header of the head skb. Consequently,skbs in the frag_list may remain untranslated, resulting in protocolinconsistencies and reduced throughput.To address this, the patch explicitly sets the SKB_GSO_DODGY flagfor GSO packets in XLAT's IPv4/IPv6 protocol translation helpers(bpf_skb_proto_4_to_6 and bpf_skb_proto_6_to_4). This marks GSOpackets as potentially modified after protocol translation. As aresult, GSO segmentation will avoid using skb_segment_list andinstead falls back to skb_segment for packets with the SKB_GSO_DODGYflag. This ensures that only safe and fully translated frag_listpackets are processed by skb_segment_list, resolving protocolinconsistencies and improving throughput when forwarding GRO packetsconverted by XLAT.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: Fix race between rfkill and nci_unregister_device().syzbot reported the splat below [0] without a repro.It indicates that struct nci_dev.cmd_wq had been destroyed beforenci_close_device() was called via rfkill.nci_dev.cmd_wq is only destroyed in nci_unregister_device(), which(I think) was called from virtual_ncidev_close() when syzbot close()dan fd of virtual_ncidev.The problem is that nci_unregister_device() destroys nci_dev.cmd_wqfirst and then calls nfc_unregister_device(), which removes thedevice from rfkill by rfkill_unregister().So, the device is still visible via rfkill even after nci_dev.cmd_wqis destroyed.Let's unregister the device from rfkill first in nci_unregister_device().Note that we cannot call nfc_unregister_device() beforenci_close_device() because 1) nfc_unregister_device() calls device_del() which frees all memory allocated by devm_kzalloc() and linked to ndev->conn_info_list 2) nci_rx_work() could try to queue nci_conn_info to ndev->conn_info_list which could be leakedThus, nfc_unregister_device() is split into two functions so wecan remove rfkill interfaces only before nci_close_device().[0]:DEBUG_LOCKS_WARN_ON(1)WARNING: kernel/locking/lockdep.c:238 at hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349WARNING: kernel/locking/lockdep.c:238 at check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349Modules linked in:CPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline]RIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline]RIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187Code: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d <67> 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1fRSP: 0018:ffffc9000c767680 EFLAGS: 00010046RAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000RDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0RBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4R10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2R13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30FS: 00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0Call Trace: lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868 touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940 __flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982 nci_close_device+0x302/0x630 net/nfc/nci/core.c:567 nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639 nfc_dev_down+0x152/0x290 net/nfc/core.c:161 nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179 rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346 rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301 vfs_write+0x29a/0xb90 fs/read_write.c:684 ksys_write+0x150/0x270 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fa59b39acb9Code: 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:00007fa5995f6028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007fa59b615fa0 RCX: 00007fa59b39acb9RDX: 0000000000000008 RSI: 0000200000000080 RDI: 0000000000000007RBP: 00007fa59b408bf7 R08: ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: toshiba_haps: Fix memory leaks in add/remove routinestoshiba_haps_add() leaks the haps object allocated by it if it returnsan error after allocating that object successfully.toshiba_haps_remove() does not free the object pointed to bytoshiba_haps before clearing that pointer, so it becomes unreachableallocated memory.Address these memory leaks by using devm_kzalloc() for allocatingthe memory in question.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: tegra: Fix a memory leak in tegra_slink_probe()In tegra_slink_probe(), when platform_get_irq() fails, it directlyreturns from the function with an error code, which causes a memory leak.Replace it with a goto label to ensure proper cleanup.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: amd: fix memory leak in acp3x pdm dma ops
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: virtio - Add spinlock protection with virtqueue notificationWhen VM boots with one virtio-crypto PCI device and builtin backend,run openssl benchmark command with multiple processes, such as openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32openssl processes will hangup and there is error reported like this: virtio_crypto virtio0: dataq.0:id 3 is not a head!It seems that the data virtqueue need protection when it is handledfor virtio done notification. If the spinlock protection is addedin virtcrypto_done_task(), openssl benchmark with multiple processesworks well.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: classmate-laptop: Add missing NULL pointer checksIn a few places in the Classmate laptop driver, code using the accelobject may run before that object's address is stored in the driverdata of the input device using it.For example, cmpc_accel_sensitivity_store_v4() is the "show" methodof cmpc_accel_sensitivity_attr_v4 which is added in cmpc_accel_add_v4(),before calling dev_set_drvdata() for inputdev->dev. If the sysfsattribute is accessed prematurely, the dev_get_drvdata(&inputdev->dev)call in in cmpc_accel_sensitivity_store_v4() returns NULL whichleads to a NULL pointer dereference going forward.Moreover, sysfs attributes using the input device are added beforeinitializing that device by cmpc_add_acpi_notify_device() and if oneof them is accessed before running that function, a NULL pointerdereference will occur.For example, cmpc_accel_sensitivity_attr_v4 is added before callingcmpc_add_acpi_notify_device() and if it is read prematurely, thedev_get_drvdata(&acpi->dev) call in cmpc_accel_sensitivity_show_v4()returns NULL which leads to a NULL pointer dereference going forward.Fix this by adding NULL pointer checks in all of the relevant places.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/siw: Fix potential NULL pointer dereference in header processingIf siw_get_hdr() returns -EINVAL before set_rx_fpdu_context(),qp->rx_fpdu can be NULL. The error path in siw_tcp_rx_data()dereferences qp->rx_fpdu->more_ddp_segs without checking, whichmay lead to a NULL pointer deref. Only check more_ddp_segs whenrx_fpdu is present.KASAN splat:[ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7][ 101.385869] RIP: 0010:siw_tcp_rx_data+0x13ad/0x1e50
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: secure_seq: add back ports to TS offsetThis reverts 28ee1b746f49 ("secure_seq: downgrade to per-host timestamp offsets")tcp_tw_recycle went away in 2017.Zhouyan Deng reported off-path TCP source port leakage viaSYN cookie side-channel that can be fixed in multiple ways.One of them is to bring back TCP ports in TS offset randomization.As a bonus, we perform a single siphash() computationto provide both an ISN and a TS offset.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-core: fix wrong reinitialization of ringbuffer on reopendvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens theDVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), whichreinitializes the waitqueue list head to empty.Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of thesame DVR device share it), this orphans any existing waitqueue entriesfrom io_uring poll or epoll, leaving them with stale prev/next pointerswhile the list head is reset to {self, self}.The waitqueue and spinlock in dvr_buffer are already properlyinitialized once in dvb_dmxdev_init(). The open path only needs toreset the buffer data pointer, size, and read/write positions.Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with directassignment of data/size and a call to dvb_ringbuffer_reset(), whichproperly resets pread, pwrite, and error with correct memory orderingwithout touching the waitqueue or spinlock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Revert "drm/amd: Check if ASPM is enabled from PCIe subsystem"This reverts commit 7294863a6f01248d72b61d38478978d638641bee.This commit was erroneously applied again after commit 0ab5d711ec74("drm/amd: Refactor `amdgpu_aspm` to be evaluated per device")removed it, leading to very hard to debug crashes, when used with a system with twoAMD GPUs of which only one supports ASPM.(cherry picked from commit 97a9689300eb2b393ba5efc17c8e5db835917080)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared blocksAs Paolo said earlier [1]:"Since the blamed commit below, classify can return TC_ACT_CONSUMED whilethe current skb being held by the defragmentation engine. As reported byGangMin Kim, if such packet is that may cause a UaF when the defrag enginelater on tries to tuch again such packet."act_ct was never meant to be used in the egress path, however some usersare attaching it to egress today [2]. Attempting to reach a middleground, we noticed that, while most qdiscs are not handlingTC_ACT_CONSUMED, clsact/ingress qdiscs are. With that in mind, weaddress the issue by only allowing act_ct to bind to clsact/ingressqdiscs and shared blocks. That way it's still possible to attach act_ct toegress (albeit only with clsact).[1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/[2] https://lore.kernel.org/netdev/cc6bfb4a-4a2b-42d8-b9ce-7ef6644fb22b@ovn.org/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: Fix possible oob access in mt76_connac2_mac_write_txwi_80211()Check frame length before accessing the mgmt fields inmt76_connac2_mac_write_txwi_80211 in order to avoid a possible oobaccess.[fix check to also cover mgmt->u.action.u.addba_req.capab,correct Fixes tag]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Use correct version for UAC3 header validationThe entry of the validators table for UAC3 AC header descriptor isdefined with the wrong protocol version UAC_VERSION_2, while it shouldhave been UAC_VERSION_3. This results in the validator never matchingfor actual UAC3 devices (protocol == UAC_VERSION_3), causing theirheader descriptors to bypass validation entirely. A malicious USBdevice presenting a truncated UAC3 header could exploit this to causeout-of-bounds reads when the driver later accesses unvalidateddescriptor fields.The bug was introduced in the same commit as the recently fixed UAC3feature unit sub-type typo, and appears to be from the same copy-pasteerror when the UAC3 section was created from the UAC2 section.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xdp: produce a warning when calculated tailroom is negativeMany ethernet drivers report xdp Rx queue frag size as being the same asDMA write size. However, the only user of this field, namelybpf_xdp_frags_increase_tail(), clearly expects a truesize.Such difference leads to unspecific memory corruption issues under certaincircumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so whenrunning xskxceiver's XDP_ADJUST_TAIL_GROW_MULTI_BUFF, 6K packet fully usesall DMA-writable space in 2 buffers. This would be fine, if onlyrxq->frag_size was properly set to 4K, but value of 3K results in anegative tailroom, because there is a non-zero page offset.We are supposed to return -EINVAL and be done with it in such case, but dueto tailroom being stored as an unsigned int, it is reported to be somewherenear UINT_MAX, resulting in a tail being grown, even if the requestedoffset is too much (it is around 2K in the abovementioned test). This laterleads to all kinds of unspecific calltraces.[ 7340.337579] xskxceiver[1440]: segfault at 1da718 ip 00007f4161aeac9d sp 00007f41615a6a00 error 6[ 7340.338040] xskxceiver[1441]: segfault at 7f410000000b ip 00000000004042b5 sp 00007f415bffecf0 error 4[ 7340.338179] in libc.so.6[61c9d,7f4161aaf000+160000][ 7340.339230] in xskxceiver[42b5,400000+69000][ 7340.340300] likely on CPU 6 (core 0, socket 6)[ 7340.340302] Code: ff ff 01 e9 f4 fe ff ff 0f 1f 44 00 00 4c 39 f0 74 73 31 c0 ba 01 00 00 00 f0 0f b1 17 0f 85 ba 00 00 00 49 8b 87 88 00 00 00 <4c> 89 70 08 eb cc 0f 1f 44 00 00 48 8d bd f0 fe ff ff 89 85 ec fe[ 7340.340888] likely on CPU 3 (core 0, socket 3)[ 7340.345088] Code: 00 00 00 ba 00 00 00 00 be 00 00 00 00 89 c7 e8 31 ca ff ff 89 45 ec 8b 45 ec 85 c0 78 07 b8 00 00 00 00 eb 46 e8 0b c8 ff ff <8b> 00 83 f8 69 74 24 e8 ff c7 ff ff 8b 00 83 f8 0b 74 18 e8 f3 c7[ 7340.404334] Oops: general protection fault, probably for non-canonical address 0x6d255010bdffc: 0000 [#1] SMP NOPTI[ 7340.405972] CPU: 7 UID: 0 PID: 1439 Comm: xskxceiver Not tainted 6.19.0-rc1+ #21 PREEMPT(lazy)[ 7340.408006] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014[ 7340.409716] RIP: 0010:lookup_swap_cgroup_id+0x44/0x80[ 7340.410455] Code: 83 f8 1c 73 39 48 ba ff ff ff ff ff ff ff 03 48 8b 04 c5 20 55 fa bd 48 21 d1 48 89 ca 83 e1 01 48 d1 ea c1 e1 04 48 8d 04 90 <8b> 00 48 83 c4 10 d3 e8 c3 cc cc cc cc 31 c0 e9 98 b7 dd 00 48 89[ 7340.412787] RSP: 0018:ffffcc5c04f7f6d0 EFLAGS: 00010202[ 7340.413494] RAX: 0006d255010bdffc RBX: ffff891f477895a8 RCX: 0000000000000010[ 7340.414431] RDX: 0001c17e3fffffff RSI: 00fa070000000000 RDI: 000382fc7fffffff[ 7340.415354] RBP: 00fa070000000000 R08: ffffcc5c04f7f8f8 R09: ffffcc5c04f7f7d0[ 7340.416283] R10: ffff891f4c1a7000 R11: ffffcc5c04f7f9c8 R12: ffffcc5c04f7f7d0[ 7340.417218] R13: 03ffffffffffffff R14: 00fa06fffffffe00 R15: ffff891f47789500[ 7340.418229] FS: 0000000000000000(0000) GS:ffff891ffdfaa000(0000) knlGS:0000000000000000[ 7340.419489] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 7340.420286] CR2: 00007f415bfffd58 CR3: 0000000103f03002 CR4: 0000000000772ef0[ 7340.421237] PKRU: 55555554[ 7340.421623] Call Trace:[ 7340.421987] [ 7340.422309] ? softleaf_from_pte+0x77/0xa0[ 7340.422855] swap_pte_batch+0xa7/0x290[ 7340.423363] zap_nonpresent_ptes.constprop.0.isra.0+0xd1/0x270[ 7340.424102] zap_pte_range+0x281/0x580[ 7340.424607] zap_pmd_range.isra.0+0xc9/0x240[ 7340.425177] unmap_page_range+0x24d/0x420[ 7340.425714] unmap_vmas+0xa1/0x180[ 7340.426185] exit_mmap+0xe1/0x3b0[ 7340.426644] __mmput+0x41/0x150[ 7340.427098] exit_mm+0xb1/0x110[ 7340.427539] do_exit+0x1b2/0x460[ 7340.427992] do_group_exit+0x2d/0xc0[ 7340.428477] get_signal+0x79d/0x7e0[ 7340.428957] arch_do_signal_or_restart+0x34/0x100[ 7340.429571] exit_to_user_mode_loop+0x8e/0x4c0[ 7340.430159] do_syscall_64+0x188/---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl: Fix race of nvdimm_bus object when creating nvdimm objectsFound issue during running of cxl-translate.sh unit test. Adding a 3ssleep right before the test seems to make the issue reproduce fairlyconsistently. The cxl_translate module has dependency on cxl_acpi andcauses orphaned nvdimm objects to reprobe after cxl_acpi is removed.The nvdimm_bus object is registered by the cxl_nvb object whencxl_acpi_probe() is called. With the nvdimm_bus object missing,__nd_device_register() will trigger NULL pointer dereference whenaccessing the dev->parent that points to &nvdimm_bus->dev.[ 192.884510] BUG: kernel NULL pointer dereference, address: 000000000000006c[ 192.895383] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20250812-19.fc42 08/12/2025[ 192.897721] Workqueue: cxl_port cxl_bus_rescan_queue [cxl_core][ 192.899459] RIP: 0010:kobject_get+0xc/0x90[ 192.924871] Call Trace:[ 192.925959] [ 192.926976] ? pm_runtime_init+0xb9/0xe0[ 192.929712] __nd_device_register.part.0+0x4d/0xc0 [libnvdimm][ 192.933314] __nvdimm_create+0x206/0x290 [libnvdimm][ 192.936662] cxl_nvdimm_probe+0x119/0x1d0 [cxl_pmem][ 192.940245] cxl_bus_probe+0x1a/0x60 [cxl_core][ 192.943349] really_probe+0xde/0x380This patch also relies on the previous change wheredevm_cxl_add_nvdimm_bridge() is called from drivers/cxl/pmem.c insteadof drivers/cxl/core.c to ensure the dependency of cxl_acpi on cxl_pmem.1. Set probe_type of cxl_nvb to PROBE_FORCE_SYNCHRONOUS to ensure the driver is probed synchronously when add_device() is called.2. Add a check in __devm_cxl_add_nvdimm_bridge() to ensure that the cxl_nvb driver is attached during cxl_acpi_probe().3. Take the cxl_root uport_dev lock and the cxl_nvb->dev lock in devm_cxl_add_nvdimm() before checking nvdimm_bus is valid.4. Set cxl_nvdimm flag to CXL_NVD_F_INVALIDATED so cxl_nvdimm_probe() will exit with -EBUSY.The removal of cxl_nvdimm devices should prevent any orphaned devicesfrom probing once the nvdimm_bus is gone.[ dj: Fixed 0-day reported kdoc issue. ][ dj: Fix cxl_nvb reference leak on error. Gregory (kreview-0811365) ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: split gc into unlink and reclaim phaseYiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service).We must split GC in an unlink and a reclaim phase.We cannot queue elements for freeing until pointers have been swapped.Expired elements are still exposed to both the packet path and userspacedumpers via the live copy of the data structure.call_rcu() does not protect us: dump operations or element lookups startingafter call_rcu has fired can still observe the free'd element, unless thecommit phase has made enough progress to swap the clone and live pointersbefore any new reader has picked up the old version.This a similar approach as done recently for the rbtree backend in commit35f83a75529a ("netfilter: nft_set_rbtree: don't gc elements on insert").
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/efi: defer freeing of boot services memoryefi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODEand EFI_BOOT_SERVICES_DATA using memblock_free_late().There are two issue with that: memblock_free_late() should be used formemory allocated with memblock_alloc() while the memory reserved withmemblock_reserve() should be freed with free_reserved_area().More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=yefi_free_boot_services() is called before deferred initialization of thememory map is complete.Benjamin Herrenschmidt reports that this causes a leak of ~140MB ofRAM on EC2 t3a.nano instances which only have 512MB or RAM.If the freed memory resides in the areas that memory map for them isstill uninitialized, they won't be actually freed becausememblock_free_late() calls memblock_free_pages() and the latter skipsuninitialized pages.Using free_reserved_area() at this point is also problematic because__free_page() accesses the buddy of the freed page and that again mightend up in uninitialized part of the memory map.Delaying the entire efi_free_boot_services() could be problematicbecause in addition to freeing boot services memory it updatesefi.memmap without any synchronization and that's undesirable late inboot when there is concurrency.More robust approach is to only defer freeing of the EFI boot servicesmemory.Split efi_free_boot_services() in two. First efi_unmap_boot_services()collects ranges that should be freed into an array thenefi_free_boot_services() later frees them after deferred init is complete.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: register phy led_triggers during probe to avoid AB-BA deadlockThere is an AB-BA deadlock when both LEDS_TRIGGER_NETDEV andLED_TRIGGER_PHY are enabled:[ 1362.049207] [<8054e4b8>] led_trigger_register+0x5c/0x1fc <-- Trying to get lock "triggers_list_lock" via down_write(&triggers_list_lock);[ 1362.054536] [<80662830>] phy_led_triggers_register+0xd0/0x234[ 1362.060329] [<8065e200>] phy_attach_direct+0x33c/0x40c[ 1362.065489] [<80651fc4>] phylink_fwnode_phy_connect+0x15c/0x23c[ 1362.071480] [<8066ee18>] mtk_open+0x7c/0xba0[ 1362.075849] [<806d714c>] __dev_open+0x280/0x2b0[ 1362.080384] [<806d7668>] __dev_change_flags+0x244/0x24c[ 1362.085598] [<806d7698>] dev_change_flags+0x28/0x78[ 1362.090528] [<807150e4>] dev_ioctl+0x4c0/0x654 <-- Hold lock "rtnl_mutex" by calling rtnl_lock();[ 1362.094985] [<80694360>] sock_ioctl+0x2f4/0x4e0[ 1362.099567] [<802e9c4c>] sys_ioctl+0x32c/0xd8c[ 1362.104022] [<80014504>] syscall_common+0x34/0x58Here LED_TRIGGER_PHY is registering LED triggers during phy_attachwhile holding RTNL and then taking triggers_list_lock.[ 1362.191101] [<806c2640>] register_netdevice_notifier+0x60/0x168 <-- Trying to get lock "rtnl_mutex" via rtnl_lock();[ 1362.197073] [<805504ac>] netdev_trig_activate+0x194/0x1e4[ 1362.202490] [<8054e28c>] led_trigger_set+0x1d4/0x360 <-- Hold lock "triggers_list_lock" by down_read(&triggers_list_lock);[ 1362.207511] [<8054eb38>] led_trigger_write+0xd8/0x14c[ 1362.212566] [<80381d98>] sysfs_kf_bin_write+0x80/0xbc[ 1362.217688] [<8037fcd8>] kernfs_fop_write_iter+0x17c/0x28c[ 1362.223174] [<802cbd70>] vfs_write+0x21c/0x3c4[ 1362.227712] [<802cc0c4>] ksys_write+0x78/0x12c[ 1362.232164] [<80014504>] syscall_common+0x34/0x58Here LEDS_TRIGGER_NETDEV is being enabled on an LED. It first takestriggers_list_lock and then RTNL. A classical AB-BA deadlock.phy_led_triggers_registers() does not require the RTNL, it does notmake any calls into the network stack which require protection. Thereis also no requirement the PHY has been attached to a MAC, thetriggers only make use of phydev state. This allows the call tophy_led_triggers_registers() to be placed elsewhere. PHY probe() andrelease() don't hold RTNL, so solving the AB-BA deadlock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell-wmi-sysman: Don't hex dump plaintext password dataset_new_password() hex dumps the entire buffer, which contains plaintextpassword data, including current and new passwords. Remove the hex dumpto avoid leaking credentials.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: rawsock: cancel tx_work before socket teardownIn rawsock_release(), cancel any pending tx_work and purge the writequeue before orphaning the socket. rawsock_tx_work runs on the systemworkqueue and calls nfc_data_exchange which dereferences the NCIdevice. Without synchronization, tx_work can race with socket anddevice teardown when a process is killed (e.g. by SIGKILL), leadingto use-after-free or leaked references.Set SEND_SHUTDOWN first so that if tx_work is already running it willsee the flag and skip transmitting, then use cancel_work_sync to waitfor any in-progress execution to finish, and finally purge anyremaining queued skbs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: ets: fix divide by zero in the offload pathOffloading ETS requires computing each class' WRR weight: this is done byaveraging over the sums of quanta as 'q_sum' and 'q_psum'. Using unsignedint, the same integer size as the individual DRR quanta, can overflow andeven cause division by zero, like it happened in the following splat: Oops: divide error: 0000 [#1] SMP PTI CPU: 13 UID: 0 PID: 487 Comm: tc Tainted: G E 6.19.0-virtme #45 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Call Trace: ets_qdisc_change+0x870/0xf40 [sch_ets] qdisc_create+0x12b/0x540 tc_modify_qdisc+0x6d7/0xbd0 rtnetlink_rcv_msg+0x168/0x6b0 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x1d6/0x2b0 netlink_sendmsg+0x22e/0x470 ____sys_sendmsg+0x38a/0x3c0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x111/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f440b81c77e Code: 4d 89 d8 e8 d4 bc 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa RSP: 002b:00007fff951e4c10 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000481820 RCX: 00007f440b81c77e RDX: 0000000000000000 RSI: 00007fff951e4cd0 RDI: 0000000000000003 RBP: 00007fff951e4c20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff951f4fa8 R13: 00000000699ddede R14: 00007f440bb01000 R15: 0000000000486980 Modules linked in: sch_ets(E) netdevsim(E) ---[ end trace 0000000000000000 ]--- RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x30000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]---Fix this using 64-bit integers for 'q_sum' and 'q_psum'.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: 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. Then, if neigh_suppress is enabled and an ICMPv6Neighbor Discovery packet reaches the bridge, br_do_suppress_nd() willdereference ipv6_stub->nd_tbl which is NULL, passing it toneigh_lookup(). This causes a kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000268 Oops: 0000 [#1] PREEMPT SMP NOPTI [...] RIP: 0010:neigh_lookup+0x16/0xe0 [...] Call Trace: ? neigh_lookup+0x16/0xe0 br_do_suppress_nd+0x160/0x290 [bridge] br_handle_frame_finish+0x500/0x620 [bridge] br_handle_frame+0x353/0x440 [bridge] __netif_receive_skb_core.constprop.0+0x298/0x1110 __netif_receive_skb_one_core+0x3d/0xa0 process_backlog+0xa0/0x140 __napi_poll+0x2c/0x170 net_rx_action+0x2c4/0x3a0 handle_softirqs+0xd0/0x270 do_softirq+0x3f/0x60Fix this by replacing IS_ENABLED(IPV6) call with ipv6_mod_enabled() inthe callers. This is in essence disabling NS/NA suppression when IPv6 isdisabled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing themIn commit 2ff5baa9b527 ("HID: appleir: Fix potential NULL dereference atraw event handle"), we handle the fact that raw event callbackscan happen even for a HID device that has not been "claimed" causing acrash if a broken device were attempted to be connected to the system.Fix up the remaining in-tree HID drivers that forgot to add this samecheck to resolve the same issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: fix incorrect buffer cleanup in gve_tx_clean_pending_packets for QPLIn DQ-QPL mode, gve_tx_clean_pending_packets() incorrectly uses the RDAbuffer cleanup path. It iterates num_bufs times and attempts to unmapentries in the dma array.This leads to two issues:1. The dma array shares storage with tx_qpl_buf_ids (union). Interpreting buffer IDs as DMA addresses results in attempting to unmap incorrect memory locations.2. num_bufs in QPL mode (counting 2K chunks) can significantly exceed the size of the dma array, causing out-of-bounds access warnings(trace below is how we noticed this issue).UBSAN: array-index-out-of-bounds indrivers/net/ethernet/drivers/net/ethernet/google/gve/gve_tx_dqo.c:178:5 index 18 is out ofrange for type 'dma_addr_t[18]' (aka 'unsigned long long[18]')Workqueue: gve gve_service_task [gve]Call Trace:dump_stack_lvl+0x33/0xa0__ubsan_handle_out_of_bounds+0xdc/0x110gve_tx_stop_ring_dqo+0x182/0x200 [gve]gve_close+0x1be/0x450 [gve]gve_reset+0x99/0x120 [gve]gve_service_task+0x61/0x100 [gve]process_scheduled_works+0x1e9/0x380Fix this by properly checking for QPL mode and delegating togve_free_tx_qpl_bufs() to reclaim the buffers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wlcore: Fix a locking bugMake sure that wl->mutex is locked before it is unlocked. This has beendetected by the Clang thread-safety analyzer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mvpp2: guard flow control update with global_tx_fc in buffer switchingmvpp2_bm_switch_buffers() unconditionally callsmvpp2_bm_pool_update_priv_fc() when switching between per-cpu andshared buffer pool modes. This function programs CM3 flow controlregisters via mvpp2_cm3_read()/mvpp2_cm3_write(), which dereferencepriv->cm3_base without any NULL check.When the CM3 SRAM resource is not present in the device tree (thethird reg entry added by commit 60523583b07c ("dts: marvell: add CM3SRAM memory to cp11x ethernet device tree")), priv->cm3_base remainsNULL and priv->global_tx_fc is false. Any operation that triggersmvpp2_bm_switch_buffers(), for example an MTU change that crossesthe jumbo frame threshold, will crash: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits pc : readl+0x0/0x18 lr : mvpp2_cm3_read.isra.0+0x14/0x20 Call trace: readl+0x0/0x18 mvpp2_bm_pool_update_fc+0x40/0x12c mvpp2_bm_pool_update_priv_fc+0x94/0xd8 mvpp2_bm_switch_buffers.isra.0+0x80/0x1c0 mvpp2_change_mtu+0x140/0x380 __dev_set_mtu+0x1c/0x38 dev_set_mtu_ext+0x78/0x118 dev_set_mtu+0x48/0xa8 dev_ifsioc+0x21c/0x43c dev_ioctl+0x2d8/0x42c sock_ioctl+0x314/0x378Every other flow control call site in the driver already guardshardware access with either priv->global_tx_fc or port->tx_fc.mvpp2_bm_switch_buffers() is the only place that omits this check.Add the missing priv->global_tx_fc guard to both the disable andre-enable calls in mvpp2_bm_switch_buffers(), consistent with therest of the driver.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In libexpat before 2.7.4, XML_ExternalEntityParserCreate does not copy unknown encoding handler user data.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libexpat1 > 0-0 (version in image is 2.7.1-150400.3.37.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: drop logically empty buckets in mtype_delmtype_del() counts empty slots below n->pos in k, but it only drops thebucket when both n->pos and k are zero. This misses buckets whose liveentries have all been removed while n->pos still points past deleted slots.Treat a bucket as empty when all positions below n->pos are unused andrelease it directly instead of shrinking it further.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bridge: mrp: reject zero test interval to avoid OOM panicbr_mrp_start_test() and br_mrp_start_in_test() accept the user-suppliedinterval value from netlink without validation. When interval is 0,usecs_to_jiffies(0) yields 0, causing the delayed work(br_mrp_test_work_expired / br_mrp_in_test_work_expired) to rescheduleitself with zero delay. This creates a tight loop on system_percpu_wqthat allocates and transmits MRP test frames at maximum rate, exhaustingall system memory and causing a kernel panic via OOM deadlock.The same zero-interval issue applies to br_mrp_start_in_test_parse()for interconnect test frames.Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for bothIFLA_BRIDGE_MRP_START_TEST_INTERVAL andIFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at thenetlink attribute parsing layer before the value ever reaches theworkqueue scheduling code. This is consistent with how other bridgesubsystems (br_fdb, br_mst) enforce range constraints on netlinkattributes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: avoid dereferencing log items after push callbacksAfter xfsaild_push_item() calls iop_push(), the log item may have beenfreed if the AIL lock was dropped during the push. Background inodereclaim or the dquot shrinker can free the log item while the AIL lockis not held, and the tracepoints in the switch statement dereferencethe log item after iop_push() returns.Fix this by capturing the log item type, flags, and LSN before callingxfsaild_push_item(), and introducing a new xfs_ail_push_class traceevent class that takes these pre-captured values and the ailp pointerinstead of the log item pointer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: save ailp before dropping the AIL lock in push callbacksIn xfs_inode_item_push() and xfs_qm_dquot_logitem_push(), the AIL lockis dropped to perform buffer IO. Once the cluster buffer no longerprotects the log item from reclaim, the log item may be freed bybackground reclaim or the dquot shrinker. The subsequent spin_lock()call dereferences lip->li_ailp, which is a use-after-free.Fix this by saving the ailp pointer in a local variable while the AILlock is held and the log item is guaranteed to be valid.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: stop reclaim before pushing AIL during unmountThe unmount sequence in xfs_unmount_flush_inodes() pushed the AIL whilebackground reclaim and inodegc are still running. This is brokenindependently of any use-after-free issues - background reclaim andinodegc should not be running while the AIL is being pushed duringunmount, as inodegc can dirty and insert inodes into the AIL during theflush, and background reclaim can race to abort and free dirty inodes.Reorder xfs_unmount_flush_inodes() to stop inodegc and cancel backgroundreclaim before pushing the AIL. Stop inodegc before cancellingm_reclaim_work because the inodegc worker can re-queue m_reclaim_workvia xfs_inodegc_set_reclaimable.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: isotp: fix tx.buf use-after-free in isotp_sendmsg()isotp_sendmsg() uses only cmpxchg() on so->tx.state to serialize accessto so->tx.buf. isotp_release() waits for ISOTP_IDLE viawait_event_interruptible() and then calls kfree(so->tx.buf).If a signal interrupts the wait_event_interruptible() inside close()while tx.state is ISOTP_SENDING, the loop exits early and releaseproceeds to force ISOTP_SHUTDOWN and continues to kfree(so->tx.buf)while sendmsg may still be reading so->tx.buf for the final CAN framein isotp_fill_dataframe().The so->tx.buf can be allocated once when the standard tx.buf length needsto be extended. Move the kfree() of this potentially extended tx.buf tosk_destruct time when either isotp_sendmsg() and isotp_release() are done.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: Initialize free_qp completion before using itIn irdma_create_qp, if ib_copy_to_udata fails, it will callirdma_destroy_qp to clean up which will attempt to wait onthe free_qp completion, which is not initialized yet. Fix thisby initializing the completion before the ib_copy_to_udata call.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Fix dangling pointer on mgmt_add_adv_patterns_monitor_completeThis fixes the condition checking so mgmt_pending_valid is executedwhenever status != -ECANCELED otherwise calling mgmt_pending_free(cmd)would kfree(cmd) without unlinking it from the list first, leaving adangling pointer. Any subsequent list traversal (e.g.,mgmt_pending_foreach during __mgmt_power_off, or anothermgmt_pending_valid call) would dereference freed memory.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: ensure we're polling a polled queueA user can change the polled queue count at run time. There's a briefwindow during a reset where a hipri task may try to poll that queuebefore the block layer has updated the queue maps, which would race withthe now interrupt driven queue and may cause double completions.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()When querying a nexthop object via RTM_GETNEXTHOP, the kernel currentlyallocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient forsingle nexthops and small Equal-Cost Multi-Path groups, this fixedallocation fails for large nexthop groups like 512 nexthops.This results in the following warning splat: WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608 [...] RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395) [...] Call Trace: rtnetlink_rcv_msg (net/core/rtnetlink.c:6989) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585) ___sys_sendmsg (net/socket.c:2641) __sys_sendmsg (net/socket.c:2671) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Fix this by allocating the size dynamically using nh_nlmsg_size() andusing nlmsg_new(), this is consistent with nexthop_notify() behavior. Inaddition, adjust nh_nlmsg_size_grp() so it calculates the size neededbased on flags passed. While at it, also add the size of NHA_FDB fornexthop group size calculation as it was missing too.This cannot be reproduced via iproute2 as the group size is currentlylimited and the command fails as follows:addattr_l ERROR: message exceeded bound of 1048
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFC: nxp-nci: allow GPIOs to sleepAllow the firmware and enable GPIOs to sleep.This fixes a `WARN_ON' and allows the driver to operate GPIOs which areconnected to I2C GPIO expanders.-- >8 --kernel: WARNING: CPU: 3 PID: 2636 at drivers/gpio/gpiolib.c:3880 gpiod_set_value+0x88/0x98-- >8 --
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: cancel pmsr_free_wk in cfg80211_pmsr_wdev_downWhen the nl80211 socket that originated a PMSR request isclosed, cfg80211_release_pmsr() sets the request's nl_portidto zero and schedules pmsr_free_wk to process the abortasynchronously. If the interface is concurrently torn downbefore that work runs, cfg80211_pmsr_wdev_down() callscfg80211_pmsr_process_abort() directly. However, the already-scheduled pmsr_free_wk work item remains pending and may runafter the interface has been removed from the driver. Thiscould cause the driver's abort_pmsr callback to operate on atorn-down interface, leading to undefined behavior andpotential crashes.Cancel pmsr_free_wk synchronously in cfg80211_pmsr_wdev_down()before calling cfg80211_pmsr_process_abort(). This ensures anypending or in-progress work is drained before interface teardownproceeds, preventing the work from invoking the driver abortcallback after the interface is gone.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: cp2615: fix serial string NULL-deref at probeThe cp2615 driver uses the USB device serial string as the i2c adaptername but does not make sure that the string exists.Verify that the device has a serial number before accessing it to avoidtriggering a NULL-pointer dereference (e.g. with malicious devices).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Fix static_branch_dec() underflow for aql_disable.syzbot reported static_branch_dec() underflow in aql_enable_write(). [0]The problem is that aql_enable_write() does not serialise concurrentwrite()s to the debugfs.aql_enable_write() checks static_key_false(&aql_disable.key) andlater calls static_branch_inc() or static_branch_dec(), but thestate may change between the two calls.aql_disable does not need to track inc/dec.Let's use static_branch_enable() and static_branch_disable().[0]:val == 0WARNING: kernel/jump_label.c:311 at __static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288Modules linked in:CPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G U L syzkaller #0 PREEMPT(full)Tainted: [U]=USER, [L]=SOFTLOCKUPHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026RIP: 0010:__static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311Code: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 <0f> 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00RSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293RAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4RDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000aR13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98FS: 00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0Call Trace: __static_key_slow_dec_cpuslocked kernel/jump_label.c:297 [inline] __static_key_slow_dec kernel/jump_label.c:321 [inline] static_key_slow_dec+0x7c/0xc0 kernel/jump_label.c:336 aql_enable_write+0x2b2/0x310 net/mac80211/debugfs.c:343 short_proxy_write+0x133/0x1a0 fs/debugfs/file.c:383 vfs_write+0x2aa/0x1070 fs/read_write.c:684 ksys_pwrite64 fs/read_write.c:793 [inline] __do_sys_pwrite64 fs/read_write.c:801 [inline] __se_sys_pwrite64 fs/read_write.c:798 [inline] __x64_sys_pwrite64+0x1eb/0x250 fs/read_write.c:798 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f530cf9aeb9Code: 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:00007f530dd72028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012RAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010RBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000R10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000R13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet: move async event work off nvmet-wqFor target nvmet_ctrl_free() flushes ctrl->async_event_work.If nvmet_ctrl_free() runs on nvmet-wq, the flush re-enters workqueuecompletion for the same worker:-A. Async event work queued on nvmet-wq (prior to disconnect): nvmet_execute_async_event() queue_work(nvmet_wq, &ctrl->async_event_work) nvmet_add_async_event() queue_work(nvmet_wq, &ctrl->async_event_work)B. Full pre-work chain (RDMA CM path): nvmet_rdma_cm_handler() nvmet_rdma_queue_disconnect() __nvmet_rdma_queue_disconnect() queue_work(nvmet_wq, &queue->release_work) process_one_work() lock((wq_completion)nvmet-wq) <--------- 1st nvmet_rdma_release_queue_work()C. Recursive path (same worker): nvmet_rdma_release_queue_work() nvmet_rdma_free_queue() nvmet_sq_destroy() nvmet_ctrl_put() nvmet_ctrl_free() flush_work(&ctrl->async_event_work) __flush_work() touch_wq_lockdep_map() lock((wq_completion)nvmet-wq) <--------- 2ndLockdep splat: ============================================ WARNING: possible recursive locking detected 6.19.0-rc3nvme+ #14 Tainted: G N -------------------------------------------- kworker/u192:42/44933 is trying to acquire lock: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 but task is already holding lock: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660 3 locks held by kworker/u192:42/44933: #0: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660 #1: ffffc9000e6cbe28 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x660 #2: ffffffff82d4db60 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530 Workqueue: nvmet-wq nvmet_rdma_release_queue_work [nvmet_rdma] Call Trace: __flush_work+0x268/0x530 nvmet_ctrl_free+0x140/0x310 [nvmet] nvmet_cq_put+0x74/0x90 [nvmet] nvmet_rdma_free_queue+0x23/0xe0 [nvmet_rdma] nvmet_rdma_release_queue_work+0x19/0x50 [nvmet_rdma] process_one_work+0x206/0x660 worker_thread+0x184/0x320 kthread+0x10c/0x240 ret_from_fork+0x319/0x390Move async event work to a dedicated nvmet-aen-wq to avoid reentrantflush on nvmet-wq.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: spi-dw-dma: fix print error log when wait finish transactionIf an error occurs, the device may not have a current message. In thiscase, the system will crash.In this case, it's better to use dev from the struct ctlr (struct spi_controller*).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: Fix deadlock during netdev reset with active connectionsResolve deadlock that occurs when user executes netdev reset while RDMAapplications (e.g., rping) are active. The netdev reset causes icedriver to remove irdma auxiliary driver, triggering device_delete andsubsequent client removal. During client removal, uverbs_client waitsfor QP reference count to reach zero while cma_client holds the finalreference, creating circular dependency and indefinite wait in iWARPmode. Skip QP reference count wait during device reset to preventdeadlock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix fence put before wait in amdgpu_amdkfd_submit_ibamdgpu_amdkfd_submit_ib() submits a GPU job and gets a fencefrom amdgpu_ib_schedule(). This fence is used to wait for jobcompletion.Currently, the code drops the fence reference using dma_fence_put()before calling dma_fence_wait().If dma_fence_put() releases the last reference, the fence may befreed before dma_fence_wait() is called. This can lead to ause-after-free.Fix this by waiting on the fence first and releasing the referenceonly after dma_fence_wait() completes.Fixes the below:drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:697 amdgpu_amdkfd_submit_ib() warn: passing freed memory 'f' (line 696)(cherry picked from commit 8b9e5259adc385b61a6590a13b82ae0ac2bd3482)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/mm: Add missing secure storage access fixups for donated memoryThere are special cases where secure storage access exceptions happenin a kernel context for pages that don't have the PG_arch_1 bitset. That bit is set for non-exported guest secure storage (memory)but is absent on storage donated to the Ultravisor since the kernelisn't allowed to export donated pages.Prior to this patch we would try to export the page by callingarch_make_folio_accessible() which would instantly return since thearch bit is absent signifying that the page was already exported andno further action is necessary. This leads to secure storage accessexception loops which can never be resolved.With this patch we unconditionally try to export and if that fails wefixup.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wireguard: device: use exit_rtnl callback instead of manual rtnl_lock in pre_exitwg_netns_pre_exit() manually acquires rtnl_lock() inside thepernet .pre_exit callback. This causes a hung task when anotherthread holds rtnl_mutex - the cleanup_net workqueue (or thesetup_net failure rollback path) blocks indefinitely inwg_netns_pre_exit() waiting to acquire the lock.Convert to .exit_rtnl, introduced in commit 7a60d91c690b ("net:Add ->exit_rtnl() hook to struct pernet_operations."), where theframework already holds RTNL and batches all callbacks under asingle rtnl_lock()/rtnl_unlock() pair, eliminating the contentionwindow.The rcu_assign_pointer(wg->creating_net, NULL) is safe to movefrom .pre_exit to .exit_rtnl (which runs after synchronize_rcu())because all RCU readers of creating_net either use maybe_get_net()- which returns NULL for a dying namespace with zero refcount - oraccess net->user_ns which remains valid throughout the entireops_undo_list sequence.[ Jason: added __net_exit and __read_mostly annotations that were missing. ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: alps: fix NULL pointer dereference in alps_raw_event()Commit ecfa6f34492c ("HID: Add HID_CLAIMED_INPUT guards in raw_eventcallbacks missing them") attempted to fix up the HID drivers that hadmissed the previous fix that was done in 2ff5baa9b527 ("HID: appleir:Fix potential NULL dereference at raw event handle"), but the alpsdriver was missed.Fix this up by properly checking in the hid-alps driver that it had beenclaimed correctly before attempting to process the raw event.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix call removal to use RCU safe deletionFix rxrpc call removal from the rxnet->calls list to use list_del_rcu()rather than list_del_init() to prevent stuffing up reading/proc/net/rxrpc/calls from potentially getting into an infinite loop.This, however, means that list_empty() no longer works on an entry that'sbeen deleted from the list, making it harder to detect prior deletion. Fixthis by:Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls thatare unexpectedly still on the list. Limiting the number of steps meansthere's no need to call cond_resched() or to remove calls from the listhere, thereby eliminating the need for rxrpc_put_call() to check for that.rxrpc_put_call() can then be fixed to unconditionally delete the call fromthe list as it is the only place that the deletion occurs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: pn533: allocate rx skb before consuming bytespn532_receive_buf() reports the number of accepted bytes to the serdevcore. The current code consumes bytes into recv_skb and may already handa complete frame to pn533_recv_frame() before allocating a fresh receivebuffer.If that alloc_skb() fails, the callback returns 0 even though it hasalready consumed bytes, and it leaves recv_skb as NULL for the nextreceive callback. That breaks the receive_buf() accounting contract andcan also lead to a NULL dereference on the next skb_put_u8().Allocate the receive skb lazily before consuming the next byte instead.If allocation fails, return the number of bytes already accepted.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:misc: fastrpc: possible double-free of cctx->remote_heapfastrpc_init_create_static_process() may free cctx->remote_heap on theerr_map path but does not clear the pointer. Later, fastrpc_rpmsg_remove()frees cctx->remote_heap again if it is non-NULL, which can lead to adouble-free if the INIT_CREATE_STATIC ioctl hits the error path and the rpmsgdevice is subsequently removed/unbound.Clear cctx->remote_heap after freeing it in the error path to prevent thelater cleanup from freeing it again.This issue was found by an in-house analysis workflow that extracts AST-basedinformation and runs static checks, with LLM assistance for triage, and wasconfirmed by manual code review.No hardware testing was performed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bridge: br_nd_send: validate ND option lengthsbr_nd_send() walks ND options according to option-provided lengths.A malformed option can make the parser advance beyond the computedoption 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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: gadget: fix state inconsistency on gadget init failureWhen cdns3_gadget_start() fails, the DRD hardware is left in gadget modewhile software state remains INACTIVE, creating hardware/software stateinconsistency.When switching to host mode via sysfs: echo host > /sys/class/usb_role/13180000.usb-role-switch/roleThe role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error,so cdns_role_stop() skips cleanup because state is still INACTIVE.This violates the DRD controller design specification (Figure22),which requires returning to idle state before switching roles.This leads to a synchronous external abort in xhci_gen_setup() whensetting up the host controller:[ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19[ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget[ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed...[ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller[ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP[ 1301.382485] pc : xhci_gen_setup+0xa4/0x408[ 1301.393391] backtrace: ... xhci_gen_setup+0xa4/0x408 <-- CRASH xhci_plat_setup+0x44/0x58 usb_add_hcd+0x284/0x678 ... cdns_role_set+0x9c/0xbc <-- Role switchFix by calling cdns_drd_gadget_off() in the error path to properlyclean up the DRD gadget state.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: gadget: fix NULL pointer dereference in ep_queueWhen the gadget endpoint is disabled or not yet configured, the ep->descpointer can be NULL. This leads to a NULL pointer dereference when__cdns3_gadget_ep_queue() is called, causing a kernel crash.Add a check to return -ESHUTDOWN if ep->desc is NULL, which is thestandard return code for unconfigured endpoints.This prevents potential crashes when ep_queue is called on endpointsthat are not ready.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/dsi: Don't do DSC horizontal timing adjustments in command modeStop adjusting the horizontal timing values based on thecompression ratio in command mode. Bspec seems to be tellingus to do this only in video mode, and this is also how theWindows driver does things.This should also fix a div-by-zero on some machines becausethe adjusted htotal ends up being so small that we end up withline_time_us==0 when trying to determine the vtotal value incommand mode.Note that this doesn't actually make the display on theHuawei Matebook E work, but at least the kernel no longerexplodes when the driver loads.(cherry picked from commit 0b475e91ecc2313207196c6d7fd5c53e1a878525)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: jq is a command-line JSON processor. In versions 1.8.1 and below, functions jv_setpath(), jv_getpath(), and delpaths_sorted() in jq's src/jv_aux.c use unbounded recursion whose depth is controlled by the length of a caller-supplied path array, with no depth limit enforced. An attacker can supply a JSON document containing a flat array of ~65,000 integers (~200 KB) that, when used as a path argument by a trusted jq filter, exhausts the C call stack and crashes the process with a segmentation fault (SIGSEGV). This bypass works because the existing MAX_PARSING_DEPTH (10,000) limit only protects the JSON parser, not runtime path operations where arrays can be programmatically constructed to arbitrary lengths. The impact is denial of service (unrecoverable crash) affecting any application or service that processes untrusted JSON input through jq's setpath, getpath, or delpaths builtins. This issue has been addressed in commit fb59f1491058d58bdc3e8dd28f1773d1ac690a1f.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libavahi-client3 > 0-0 (version in image is 0.8-150400.7.26.1).
-
Description: jq is a command-line JSON processor. In commits after 69785bf77f86e2ea1b4a20ca86775916889e91c9, the _strindices builtin in jq's src/builtin.c passes its arguments directly to jv_string_indexes() without verifying they are strings, and jv_string_indexes() in src/jv.c relies solely on assert() checks that are stripped in release builds compiled with -DNDEBUG. This allows an attacker to crash jq trivially with input like _strindices(0), and by crafting a numeric value whose IEEE-754 bit pattern maps to a chosen pointer, achieve a controlled pointer dereference and limited memory read/probe primitive. Any deployment that evaluates untrusted jq filters against a release build is vulnerable. This issue has been patched in commit fdf8ef0f0810e3d365cdd5160de43db46f57ed03.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.1).
-
Description: jq is a command-line JSON processor. Before commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784, jq used MurmurHash3 with a hardcoded, publicly visible seed (0x432A9843) for all JSON object hash table operations, which allowed an attacker to precompute key collisions offline. By supplying a crafted JSON object (~100 KB) where all keys hashed to the same bucket, hash table lookups degraded from O(1) to O(n), turning any jq expression into an O(n?) operation and causing significant CPU exhaustion. This affected common jq use cases such as CI/CD pipelines, web services, and data processing scripts, and was far more practical to exploit than existing heap overflow issues since it required only a small payload. This issue has been patched in commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.1).
-
Description: jq is a command-line JSON processor. In 1.8.1 and earlier, Top-level jq programs loaded from a file with -f are truncated at the first embedded NUL byte on current upstream HEAD. A crafted filter file such as . followed by \x00 and arbitrary suffix compiles and executes as only the prefix before the NUL. This leaves jq with a post-CVE-2026-33948 prefix/full-buffer mismatch on the compilation path even though the JSON parser path has already been fixed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix incorrect pruning due to atomic fetch precision trackingWhen backtrack_insn encounters a BPF_STX instruction with BPF_ATOMICand BPF_FETCH, the src register (or r0 for BPF_CMPXCHG) also acts asa destination, thus receiving the old value from the memory location.The current backtracking logic does not account for this. It treatsatomic fetch operations the same as regular stores where the srcregister is only an input. This leads the backtrack_insn to fail topropagate precision to the stack location, which is then not markedas precise!Later, the verifier's path pruning can incorrectly consider two statesequivalent when they differ in terms of stack state. Meaning, twobranches can be treated as equivalent and thus get pruned when theyshould not be seen as such.Fix it as follows: Extend the BPF_LDX handling in backtrack_insn toalso cover atomic fetch operations via is_atomic_fetch_insn() helper.When the fetch dst register is being tracked for precision, clear it,and propagate precision over to the stack slot. For non-stack memory,the precision walk stops at the atomic instruction, same as regularBPF_LDX. This covers all fetch variants.Before: 0: (b7) r1 = 8 ; R1=8 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ; R2=0 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) mark_precise: frame0: regs=r2 stack= before 2: (b7) r2 = 0 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exitAfter: 0: (b7) r1 = 8 ; R1=8 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ; R2=0 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) mark_precise: frame0: regs= stack=-8 before 2: (b7) r2 = 0 mark_precise: frame0: regs= stack=-8 before 1: (7b) *(u64 *)(r10 -8) = r1 mark_precise: frame0: regs=r1 stack= before 0: (b7) r1 = 8 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exit
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Reject sleepable kprobe_multi programs at attach timekprobe.multi programs run in atomic/RCU context and cannot sleep.However, bpf_kprobe_multi_link_attach() did not validate whether theprogram being attached had the sleepable flag set, allowing sleepablehelpers such as bpf_copy_from_user() to be invoked from a non-sleepablecontext.This causes a "sleeping function called from invalid context" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0Fix this by rejecting sleepable programs early inbpf_kprobe_multi_link_attach(), before any further processing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: lag: Check for LAG device before creating debugfs__mlx5_lag_dev_add_mdev() may return 0 (success) even when an erroroccurs that is handled gracefully. Consequently, the initializationflow proceeds to call mlx5_ldev_add_debugfs() even when there is novalid LAG context.mlx5_ldev_add_debugfs() blindly created the debugfs directory andattributes. This exposed interfaces (like the members file) that rely ona valid ldev pointer, leading to potential NULL pointer dereferences ifaccessed when ldev is NULL.Add a check to verify that mlx5_lag_dev(dev) returns a valid pointerbefore attempting to create the debugfs entries.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: sockmap: Fix use-after-free of sk->sk_socket in sk_psock_verdict_data_ready().syzbot reported use-after-free of AF_UNIX socket's sk->sk_socketin sk_psock_verdict_data_ready(). [0]In unix_stream_sendmsg(), the peer socket's ->sk_data_ready() iscalled after dropping its unix_state_lock().Although the sender socket holds the peer's refcount, it does notprevent the peer's sock_orphan(), and the peer's sk_socket mightbe freed after one RCU grace period.Let's fetch the peer's sk->sk_socket and sk->sk_socket->ops underRCU in sk_psock_verdict_data_ready().[0]:BUG: KASAN: slab-use-after-free in sk_psock_verdict_data_ready+0xec/0x590 net/core/skmsg.c:1278Read of size 8 at addr ffff8880594da860 by task syz.4.1842/11013CPU: 1 UID: 0 PID: 11013 Comm: syz.4.1842 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xba/0x230 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 sk_psock_verdict_data_ready+0xec/0x590 net/core/skmsg.c:1278 unix_stream_sendmsg+0x8a3/0xe80 net/unix/af_unix.c:2482 sock_sendmsg_nosec net/socket.c:721 [inline] __sock_sendmsg net/socket.c:736 [inline] ____sys_sendmsg+0x972/0x9f0 net/socket.c:2585 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2639 __sys_sendmsg net/socket.c:2671 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2674 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:0x7facf899c819Code: 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:00007facf9827028 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007facf8c15fa0 RCX: 00007facf899c819RDX: 0000000000000000 RSI: 0000200000000500 RDI: 0000000000000004RBP: 00007facf8a32c91 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007facf8c16038 R14: 00007facf8c15fa0 R15: 00007ffd41b01c78 Allocated by task 11013: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 unpoison_slab_object mm/kasan/common.c:340 [inline] __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366 kasan_slab_alloc include/linux/kasan.h:253 [inline] slab_post_alloc_hook mm/slub.c:4538 [inline] slab_alloc_node mm/slub.c:4866 [inline] kmem_cache_alloc_lru_noprof+0x2b8/0x640 mm/slub.c:4885 sock_alloc_inode+0x28/0xc0 net/socket.c:316 alloc_inode+0x6a/0x1b0 fs/inode.c:347 new_inode_pseudo include/linux/fs.h:3003 [inline] sock_alloc net/socket.c:631 [inline] __sock_create+0x12d/0x9d0 net/socket.c:1562 sock_create net/socket.c:1656 [inline] __sys_socketpair+0x1c4/0x560 net/socket.c:1803 __do_sys_socketpair net/socket.c:1856 [inline] __se_sys_socketpair net/socket.c:1853 [inline] __x64_sys_socketpair+0x9b/0xb0 net/socket.c:1853 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/0x7fFreed by task 15: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 [inline] __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:2685 [inline] slab_free mm/slub.c:6165 [inline] kmem_cache_free+0x187/0x630 mm/slub.c:6295 rcu_do_batch kernel/rcu/tree.c:---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: fix potential UAF in hci_le_remote_conn_param_req_evthci_conn lookup and field access must be covered by hdev lock inhci_le_remote_conn_param_req_evt, otherwise it's possible it is freedconcurrently.Extend the hci_dev_lock critical section to cover all conn usage.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix regsafe() for pointers to packetIn case rold->reg->range == BEYOND_PKT_END && rcur->reg->range == Nregsafe() may return true which may lead to current state withvalid packet range not being explored. Fix the bug.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFC: pn533: bound the UART receive bufferpn532_receive_buf() appends every incoming byte to dev->recv_skb andonly resets the buffer after pn532_uart_rx_is_frame() recognizes acomplete frame. A continuous stream of bytes without a valid PN532 frameheader therefore keeps growing the skb until skb_put_u8() hits the taillimit.Drop the accumulated partial frame once the fixed receive buffer is fullso malformed UART traffic cannot grow the skb pastPN532_UART_SKB_BUFF_LEN.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory leak__radix_tree_create() allocates and links intermediate nodes into thetree one by one. If a subsequent allocation fails, the already-linkednodes remain in the tree with no corresponding leaf entry. These orphanedinternal nodes are never reclaimed because radix_tree_for_each_slot()only visits slots containing leaf values.The radix_tree API is deprecated in favor of xarray. As suggested byMatthew Wilcox, migrate qrtr_tx_flow from radix_tree to xarray insteadof fixing the radix_tree itself [1]. xarray properly handles cleanup ofinternal nodes - xa_destroy() frees all internal xarray nodes when theqrtr_node is released, preventing the leak.[1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failurePresently, if the force feedback initialisation fails when probing theLogitech G920 Driving Force Racing Wheel for Xbox One, an error numberwill be returned and propagated before the userspace infrastructure(sysfs and /dev/input) has been torn down. If userspace ignores theerrors and continues to use its references to these dangling entities, aUAF will promptly follow.We have 2 options; continue to return the error, but ensure that all ofthe infrastructure is torn down accordingly or continue to treat thiscondition as a warning by emitting the message but returning success.It is thought that the original author's intention was to emit thewarning but keep the device functional, less the force feedback feature,so let's go with that.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: close crash window in attr dabtree inactivationWhen inactivating an inode with node-format extended attributes,xfs_attr3_node_inactive() invalidates all child leaf/node blocks viaxfs_trans_binval(), but intentionally does not remove the correspondingentries from their parent node blocks. The implicit assumption is thatxfs_attr_inactive() will truncate the entire attr fork to zero extentsafterwards, so log recovery will never reach the root node and followthose stale pointers.However, if a log shutdown occurs after the leaf/node block cancellationscommit but before the attr bmap truncation commits, this assumptionbreaks. Recovery replays the attr bmap intact (the inode still hasattr fork extents), but suppresses replay of all cancelled leaf/nodeblocks, maybe leaving them as stale data on disk. On the next mount,xlog_recover_process_iunlinks() retries inactivation and attempts toread the root node via the attr bmap. If the root node was not replayed,reading the unreplayed root block triggers a metadata verificationfailure immediately; if it was replayed, following its child pointersto unreplayed child blocks triggers the same failure: XFS (pmem0): Metadata corruption detected at xfs_da3_node_read_verify+0x53/0x220, xfs_da3_node block 0x78 XFS (pmem0): Unmount and run xfs_repair XFS (pmem0): First 128 bytes of corrupted metadata buffer: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ XFS (pmem0): metadata I/O error in "xfs_da_read_buf+0x104/0x190" at daddr 0x78 len 8 error 117Fix this in two places:In xfs_attr3_node_inactive(), after calling xfs_trans_binval() on achild block, immediately remove the entry that references it from theparent node in the same transaction. This eliminates the window wherethe parent holds a pointer to a cancelled block. Once all children areremoved, the now-empty root node is converted to a leaf block within thesame transaction. This node-to-leaf conversion is necessary for crashsafety. If the system shutdown after the empty node is written to thelog but before the second-phase bmap truncation commits, log recoverywill attempt to verify the root block on disk. xfs_da3_node_verify()does not permit a node block with count == 0; such a block will failverification and trigger a metadata corruption shutdown. on the otherhand, leaf blocks are allowed to have this transient state.In xfs_attr_inactive(), split the attr fork truncation into two explicitphases. First, truncate all extents beyond the root block (the childextents whose parent references have already been removed above).Second, invalidate the root block and truncate the attr bmap to zero ina single transaction. The two operations in the second phase must beatomic: as long as the attr bmap has any non-zero length, recovery canfollow it to the root block, so the root block invalidation must committogether with the bmap-to-zero truncation.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Drain commands in target_reset handlertcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESSwithout draining any in-flight commands. The SCSI EH documentation(scsi_eh.rst) requires that when a reset handler returns SUCCESS the driverhas made lower layers "forget about timed out scmds" and is ready for newcommands. Every other SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug,mpi3mr) enforces this by draining or completing outstanding commands beforereturning SUCCESS.Because tcm_loop_target_reset() doesn't drain, the SCSI EH reuses in-flightscsi_cmnd structures for recovery commands (e.g. TUR) while the target corestill has async completion work queued for the old se_cmd. The memset inqueuecommand zeroes se_lun and lun_ref_active, causingtransport_lun_remove_cmd() to skip its percpu_ref_put(). The leaked LUNreference prevents transport_clear_lun_ref() from completing, hangingconfigfs LUN unlink forever in D-state: INFO: task rm:264 blocked for more than 122 seconds. rm D 0 264 258 0x00004000 Call Trace: __schedule+0x3d0/0x8e0 schedule+0x36/0xf0 transport_clear_lun_ref+0x78/0x90 [target_core_mod] core_tpg_remove_lun+0x28/0xb0 [target_core_mod] target_fabric_port_unlink+0x50/0x60 [target_core_mod] configfs_unlink+0x156/0x1f0 [configfs] vfs_unlink+0x109/0x290 do_unlinkat+0x1d5/0x2d0Fix this by making tcm_loop_target_reset() actually drain commands: 1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that the target core knows about (those not yet CMD_T_COMPLETE). 2. Use blk_mq_tagset_busy_iter() to iterate all started requests and flush_work() on each se_cmd - this drains any deferred completion work for commands that already had CMD_T_COMPLETE set before the TMR (which the TMR skips via __target_check_io_state()). This is the same pattern used by mpi3mr, scsi_debug, and libsas to drain outstanding commands during reset.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mana: fix use-after-free in add_adev() error pathIf auxiliary_device_add() fails, add_adev() jumps to add_fail and callsauxiliary_device_uninit(adev).The auxiliary device has its release callback set to adev_release(),which frees the containing struct mana_adev. Since adev is embedded instruct mana_adev, the subsequent fall-through to init_fail and accessto adev->id may result in a use-after-free.Fix this by saving the allocated auxiliary device id in a localvariable before calling auxiliary_device_add(), and use that saved idin the cleanup path after auxiliary_device_uninit().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Fix list corruption and UAF in command complete handlersCommit 302a1f674c00 ("Bluetooth: MGMT: Fix possible UAFs") introducedmgmt_pending_valid(), which not only validates the pending command butalso unlinks it from the pending list if it is valid. This change insemantics requires updates to several completion handlers to avoid listcorruption and memory safety issues.This patch addresses two left-over issues from the aforementioned rework:1. In mgmt_add_adv_patterns_monitor_complete(), mgmt_pending_remove()is replaced with mgmt_pending_free() in the success path. Sincemgmt_pending_valid() already unlinks the command at the beginning ofthe function, calling mgmt_pending_remove() leads to a double list_del()and subsequent list corruption/kernel panic.2. In set_mesh_complete(), the use of mgmt_pending_foreach() in the errorpath is removed. Since the current command is already unlinked bymgmt_pending_valid(), this foreach loop would incorrectly target otherpending mesh commands, potentially freeing them while they are still beingprocessed concurrently (leading to UAFs). The redundant mgmt_cmd_status()is also simplified to use cmd->opcode directly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: drop pending enqueued packets on removalPackets sitting in nfqueue might hold a reference to:- templates that specify the conntrack zone, because a percpu area is used and module removal is possible.- conntrack timeout policies and helper, where object removal leave a stale reference.Since these objects can just go away, drop enqueued packets to avoidstale reference to them.If there is a need for finer grain removal, this logic can be revisitedto make selective packet drop upon dependencies.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix type confusion in l2cap_ecred_reconf_rsp()l2cap_ecred_reconf_rsp() casts the incoming data to structl2cap_ecred_conn_rsp (the ECRED *connection* response, 8 bytes withresult at offset 6) instead of struct l2cap_ecred_reconf_rsp (2 byteswith result at offset 0).This causes two problems: - The sizeof(*rsp) length check requires 8 bytes instead of the correct 2, so valid L2CAP_ECRED_RECONF_RSP packets are rejected with -EPROTO. - rsp->result reads from offset 6 instead of offset 0, returning wrong data when the packet is large enough to pass the check.Fix by using the correct type. Also pass the already byte-swappedresult variable to BT_DBG instead of the raw __le16 field.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Fix not releasing workqueue on .release()The workqueue associated with an DSA/IAA device is not released whenthe object is freed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vc4: platform_get_irq_byname() returns an intplatform_get_irq_byname() will return a negative value if an errorhappens, so it should be checked and not just passed directly intodevm_request_threaded_irq() hoping all will be ok.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel/uncore: Skip discovery table for offline diesThis warning can be triggered if NUMA is disabled and the systemboots with fewer CPUs than the number of CPUs in die 0.WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore]Currently, the discovery table continues to be parsed even if all CPUsin the associated die are offline. This can lead to an array overflowat "pmu->boxes[die] = box" in uncore_pci_pmu_register(), which maytrigger the warning above or cause other issues.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix NULL deref in ip_vs_add_service error pathWhen ip_vs_bind_scheduler() succeeds in ip_vs_add_service(), the localvariable sched is set to NULL. If ip_vs_start_estimator() subsequentlyfails, the out_err cleanup calls ip_vs_unbind_scheduler(svc, sched)with sched == NULL. ip_vs_unbind_scheduler() passes the cur_sched NULLcheck (because svc->scheduler was set by the successful bind) but thendereferences the NULL sched parameter at sched->done_service, causing akernel panic at offset 0x30 from NULL. Oops: general protection fault, [..] [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] RIP: 0010:ip_vs_unbind_scheduler (net/netfilter/ipvs/ip_vs_sched.c:69) Call Trace: ip_vs_add_service.isra.0 (net/netfilter/ipvs/ip_vs_ctl.c:1500) do_ip_vs_set_ctl (net/netfilter/ipvs/ip_vs_ctl.c:2809) nf_setsockopt (net/netfilter/nf_sockopt.c:102) [..]Fix by simply not clearing the local sched variable after a successfulbind. ip_vs_unbind_scheduler() already detects whether a scheduler isinstalled via svc->scheduler, and keeping sched non-NULL ensures theerror path passes the correct pointer to both ip_vs_unbind_scheduler()and ip_vs_scheduler_put().While the bug is older, the problem popups in more recent kernels (6.2),when the new error path is taken after the ip_vs_start_estimator() call.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: s3fwrn5: allocate rx skb before consuming bytess3fwrn82_uart_read() reports the number of accepted bytes to the serdevcore. The current code consumes bytes into recv_skb and may alreadydeliver a complete frame before allocating a fresh receive buffer.If that alloc_skb() fails, the callback returns 0 even though it hasalready consumed bytes, and it leaves recv_skb as NULL for the nextreceive callback. That breaks the receive_buf() accounting contract andcan also lead to a NULL dereference on the next skb_put_u8().Allocate the receive skb lazily before consuming the next byte instead.If allocation fails, return the number of bytes already accepted.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: icmp: fix null-ptr-deref in icmp_build_probe()ipv6_stub->ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when theIPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passingthis error pointer to dev_hold() will cause a kernel crash withnull-ptr-deref.Instead, silently discard the request. RFC 8335 does not appear todefine a specific response for the case where an IPv6 interfaceidentifier is syntactically valid but the implementation cannot performthe lookup at runtime, and silently dropping the request may safer thanmisreporting "No Such Interface".
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: account XFRMA_IF_ID in aevent size calculationxfrm_get_ae() allocates the reply skb with xfrm_aevent_msgsize(), thenbuild_aevent() appends attributes including XFRMA_IF_ID when x->if_id isset.xfrm_aevent_msgsize() does not include space for XFRMA_IF_ID. For stateswith if_id, build_aevent() can fail with -EMSGSIZE and hit BUG_ON(err < 0)in xfrm_get_ae(), turning a malformed netlink interaction into a kernelpanic.Account XFRMA_IF_ID in the size calculation unconditionally and replacethe BUG_ON with normal error unwinding.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepathWhen cifs_sanitize_prepath is called with an empty string or a stringcontaining only delimiters (e.g., "/"), the current logic attempts tocheck *(cursor2 - 1) before cursor2 has advanced. This results in anout-of-bounds read.This patch adds an early exit check after stripping prependeddelimiters. If no path content remains, the function returns NULL.The bug was identified via manual audit and verified using astandalone test case compiled with AddressSanitizer, whichtriggered a SEGV on affected inputs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiryNew test case fails unexpectedly when avx2 matching functions are used.The test first loads a ranomly generated pipapo setwith 'ipv4 . port' key, i.e. nft -f foo.This works. Then, it reloads the set after a flush:(echo flush set t s; cat foo) | nft -f -This is expected to work, because its the same set after all and it wasalready loaded once.But with avx2, this fails: nft reports a clashing element.The reported clash is of following form: We successfully re-inserted a . b c . dThen we try to insert a . davx2 finds the already existing a . d, which (due to 'flush set') is markedas invalid in the new generation. It skips the element and moves to next.Due to incorrect masking, the skip-step finds the next matchingelement *only considering the first field*,i.e. we return the already reinserted "a . b", even though thelast field is different and the entry should not have been matched.No such error is reported for the generic c implementation (no avx2) or whenthe last field has to use the 'nft_pipapo_avx2_lookup_slow' fallback.Bisection points to7711f4bb4b36 ("netfilter: nft_set_pipapo: fix range overlap detection")but that fix merely uncovers this bug.Before this commit, the wrong element is returned, but erronouslyreported as a full, identical duplicate.The root-cause is too early return in the avx2 match functions.When we process the last field, we should continue to process datauntil the entire input size has been consumed to make sure no stalebits remain in the map.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/umem: Fix double dma_buf_unpin in failure pathIn ib_umem_dmabuf_get_pinned_with_dma_device(), the call toib_umem_dmabuf_map_pages() can fail. If this occurs, the dmabufis immediately unpinned but the umem_dmabuf->pinned flag is stillset. Then, when ib_umem_release() is called, it callsib_umem_dmabuf_revoke() which will call dma_buf_unpin() again.Fix this by removing the immediate unpin upon failure and just letthe ib_umem_release/revoke path handle it. This also ensures theproper unmap-unpin unwind ordering if the dmabuf_map_pages callhappened to fail due to dma_resv_wait_timeout (and therefore hasa non-NULL umem_dmabuf->sgt).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable modeCommit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidationrequest when device is disconnected") relies onpci_dev_is_disconnected() to skip ATS invalidation forsafely-removed devices, but it does not cover link-down causedby faults, which can still hard-lock the system.For example, if a VM fails to connect to the PCIe device,"virsh destroy" is executed to release resources and isolatethe fault, but a hard-lockup occurs while releasing the group fd.Call Trace: qi_submit_sync qi_flush_dev_iotlb intel_pasid_tear_down_entry device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fputAlthough pci_device_is_present() is slower thanpci_dev_is_disconnected(), it still takes only ~70 ?s on aConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speedand width increase.Besides, devtlb_invalidation_with_pasid() is called only in thepaths below, which are far less frequent than memory map/unmap.1. mm-struct release2. {attach,release}_dev3. set/remove PASID4. dirty-tracking setupThe gain in system stability far outweighs the negligible costof using pci_device_is_present() instead of pci_dev_is_disconnected()to decide when to skip ATS invalidation, especially under GDRhigh-load conditions.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulationCommit cc3ed80ae69f ("KVM: nSVM: always use vmcb01 to for vmsave/vmloadof guest state") made KVM always use vmcb01 for the fields controlled byVMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation codeto always use vmcb01.As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is notintercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01instead of the current VMCB.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: cx23885: Add missing unmap in snd_cx23885_hw_params()In error path, add cx23885_alsa_dma_unmap() to release theresource acquired by cx23885_alsa_dma_map().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: logitech-hidpp: Check maxfield in hidpp_get_report_length()Do not crash when a report has no fields.Fake USB gadgets can send their own HID report descriptors and can define reportstructures without valid fields. This can be used to crash the kernel over USB.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Intel: hda: Fix NULL pointer dereferenceIf there's a mismatch between the DAI links in the machine driver andthe topology, it is possible that the playback/capture widget is notset, especially in the case of loopback capture for echo referencewhere we use the dummy DAI link. Return the error when the widget is notset to avoid a null pointer dereference like below when the topology isbroken.RIP: 0010:hda_dai_get_ops.isra.0+0x14/0xa0 [snd_sof_intel_hda_common]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mfd: core: Add locking around 'mfd_of_node_list'Manipulating a list in the kernel isn't safe without some sort ofmutual exclusion. Add a mutex any time we access / modify'mfd_of_node_list' to prevent possible crashes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/smp: Add check for kcalloc() failure in parse_thread_groups()As kcalloc() may fail, check its return value to avoid a NULL pointerdereference when passing it to of_property_read_u32_array().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-af: CGX: fix bitmap leaksThe RX/TX flow-control bitmaps (rx_fc_pfvf_bmap and tx_fc_pfvf_bmap)are allocated by cgx_lmac_init() but never freed in cgx_lmac_exit().Unbinding and rebinding the driver therefore triggers kmemleak: unreferenced object (size 16): backtrace: rvu_alloc_bitmap cgx_probeFree both bitmaps during teardown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Skip dev-iotlb flush for inaccessible PCIe device without scalable modePCIe endpoints with ATS enabled and passed through to userspace(e.g., QEMU, DPDK) can hard-lock the host when their link drops,either by surprise removal or by a link fault.Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidationrequest when device is disconnected") adds pci_dev_is_disconnected()to devtlb_invalidation_with_pasid() so ATS invalidation is skippedonly when the device is being safely removed, but it applies onlywhen Intel IOMMU scalable mode is enabled.With scalable mode disabled or unsupported, a system hard-lockoccurs when a PCIe endpoint's link drops because the Intel IOMMUwaits indefinitely for an ATS invalidation that cannot complete.Call Trace: qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 domain_context_clear_one_cb pci_for_each_dma_alias device_block_translation blocking_domain_attach_dev iommu_deinit_device __iommu_group_remove_device iommu_release_device iommu_bus_notifier blocking_notifier_call_chain bus_notify device_del pci_remove_bus_device pci_stop_and_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_istCommit 81e921fd3216 ("iommu/vt-d: Fix NULL domain on device release")adds intel_pasid_teardown_sm_context() to intel_iommu_release_device(),which calls qi_flush_dev_iotlb() and can also hard-lock the systemwhen a PCIe endpoint's link drops.Call Trace: qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 intel_context_flush_no_pasid device_pasid_table_teardown pci_pasid_table_teardown pci_for_each_dma_alias intel_pasid_teardown_sm_context intel_iommu_release_device iommu_deinit_device __iommu_group_remove_device iommu_release_device iommu_bus_notifier blocking_notifier_call_chain bus_notify device_del pci_remove_bus_device pci_stop_and_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_istSometimes the endpoint loses connection without a link-down event(e.g., due to a link fault); killing the process (virsh destroy)then hard-locks the host.Call Trace: qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 domain_context_clear_one_cb pci_for_each_dma_alias device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fputpci_dev_is_disconnected() only covers safe-removal paths;pci_device_is_present() tests accessibility by readingvendor/device IDs and internally calls pci_dev_is_disconnected().On a ConnectX-5 (8 GT/s, x2) this costs ~70 ?s.Since __context_flush_dev_iotlb() is only called on{attach,release}_dev paths (not hot), add pci_device_is_present()there to skip inaccessible devices and avoid the hard-lock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: tegra-video: Fix memory leak in __tegra_channel_try_format()The state object allocated by __v4l2_subdev_state_alloc() must be freedwith __v4l2_subdev_state_free() when it is no longer needed.In __tegra_channel_try_format(), two error paths return directly afterv4l2_subdev_call() fails, without freeing the allocated 'sd_state'object. This violates the requirement and causes a memory leak.Fix this by introducing a cleanup label and using goto statements in theerror paths to ensure that __v4l2_subdev_state_free() is always calledbefore the function returns.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: gadget: Move vbus draw to workqueue contextCurrently dwc3_gadget_vbus_draw() can be called from atomiccontext, which in turn invokes power-supply-core APIs. Andsome these PMIC APIs have operations that may sleep, leadingto kernel panic.Fix this by moving the vbus_draw into a workqueue context.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:EFI/CPER: don't dump the entire memory regionThe current logic at cper_print_fw_err() doesn't check if theerror record length is big enough to handle offset. On a bad firmware,if the ofset is above the actual record, length -= offset willunderflow, making it dump the entire memory.The end result can be: - the logic taking a lot of time dumping large regions of memory; - data disclosure due to the memory dumps; - an OOPS, if it tries to dump an unmapped memory region.Fix it by checking if the section length is too small before doinga hex dump.[ rjw: Subject tweaks ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: fix 22000 series SMEM parsingIf the firmware were to report three LMACs (which doesn'texist in hardware) then using "fwrt->smem_cfg.lmac[2]" isan overrun of the array. Reject such and use IWL_FW_CHECKinstead of WARN_ON in this function.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: ti: pruss: Fix double free in pruss_clk_mux_setup()In the pruss_clk_mux_setup(), the devm_add_action_or_reset() indirectlycalls pruss_of_free_clk_provider(), which calls of_node_put(clk_mux_np)on the error path. However, after the devm_add_action_or_reset()returns, the of_node_put(clk_mux_np) is called again, causing a doublefree.Fix by returning directly, to avoid the duplicate of_node_put().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: Fix swapped parameters in pci_{primary/secondary}_epc_epf_unlink() functionsstruct configfs_item_operations callbacks are defined like the following: int (*allow_link)(struct config_item *src, struct config_item *target); void (*drop_link)(struct config_item *src, struct config_item *target);While pci_primary_epc_epf_link() and pci_secondary_epc_epf_link() specifythe parameters in the correct order, pci_primary_epc_epf_unlink() andpci_secondary_epc_epf_unlink() specify the parameters in the wrong order,leading to the below kernel crash when using the unlink command inconfigfs: Unable to handle kernel paging request at virtual address 0000000300000857 Mem abort info: ... pc : string+0x54/0x14c lr : vsnprintf+0x280/0x6e8 ... string+0x54/0x14c vsnprintf+0x280/0x6e8 vprintk_default+0x38/0x4c vprintk+0xc4/0xe0 pci_epf_unbind+0xdc/0x108 configfs_unlink+0xe0/0x208+0x44/0x74 vfs_unlink+0x120/0x29c __arm64_sys_unlinkat+0x3c/0x90 invoke_syscall+0x48/0x134 do_el0_svc+0x1c/0x30prop.0+0xd0/0xf0[mani: cced stable, changed commit message as per https://lore.kernel.org/linux-pci/aV9joi3jF1R6ca02@ryzen]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: qcom: q6asm: drop DSP responses for closed data streams'Commit a354f030dbce ("ASoC: qcom: q6asm: handle the responsesafter closing")' attempted to ignore DSP responses arrivingafter a stream had been closed.However, those responses were still handled, causing lockups.Fix this by unconditionally dropping all DSP responses associated withclosed data streams.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dpaa2-switch: validate num_ifs to prevent out-of-bounds writeThe driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes()but never validates it against DPSW_MAX_IF (64). This value controlsiteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indicesinto the fixed-size cfg->if_id[DPSW_MAX_IF] array. When firmware reportsnum_ifs >= 64, the loop can write past the array bounds.Add a bound check for num_ifs in dpaa2_switch_init().dpaa2_switch_fdb_get_flood_cfg() appends the control interface (portnum_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and allports match the flood filter, the loop fills all 64 slots and the controlinterface write overflows by one entry.The check uses >= because num_ifs == DPSW_MAX_IF is also functionallybroken.build_if_id_bitmap() silently drops any ID >= 64: if (id[i] < DPSW_MAX_IF) bmap[id[i] / 64] |= ...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw89: pci: validate sequence number of TX release reportHardware rarely reports abnormal sequence number in TX release report,which will access out-of-bounds of wd_ring->pages array, causing NULLpointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1085 Comm: irq/129-rtw89_p Tainted: G S U 6.1.145-17510-g2f3369c91536 #1 (HASH:69e8 1) Call Trace: rtw89_pci_release_tx+0x18f/0x300 [rtw89_pci (HASH:4c83 2)] rtw89_pci_napi_poll+0xc2/0x190 [rtw89_pci (HASH:4c83 2)] net_rx_action+0xfc/0x460 net/core/dev.c:6578 net/core/dev.c:6645 net/core/dev.c:6759 handle_softirqs+0xbe/0x290 kernel/softirq.c:601 ? rtw89_pci_interrupt_threadfn+0xc5/0x350 [rtw89_pci (HASH:4c83 2)] __local_bh_enable_ip+0xeb/0x120 kernel/softirq.c:499 kernel/softirq.c:423 rtw89_pci_interrupt_threadfn+0xf8/0x350 [rtw89_pci (HASH:4c83 2)] ? irq_thread+0xa7/0x340 kernel/irq/manage.c:0 irq_thread+0x177/0x340 kernel/irq/manage.c:1205 kernel/irq/manage.c:1314 ? thaw_kernel_threads+0xb0/0xb0 kernel/irq/manage.c:1202 ? irq_forced_thread_fn+0x80/0x80 kernel/irq/manage.c:1220 kthread+0xea/0x110 kernel/kthread.c:376 ? synchronize_irq+0x1a0/0x1a0 kernel/irq/manage.c:1287 ? kthread_associate_blkcg+0x80/0x80 kernel/kthread.c:331 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 To prevent crash, validate rpp_info.seq before using.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: cpsw_new: Fix potential unregister of netdev that has not been registered yetIf an error occurs during register_netdev() for the first MAC incpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL,cpsw->slaves[1].ndev would remain unchanged. This could later causecpsw_unregister_ports() to attempt unregistering the second MAC.To address this, add a check for ndev->reg_state before callingunregister_netdev(). With this change, setting cpsw->slaves[i].ndevto NULL becomes unnecessary and can be removed accordingly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: prevent races in ->query_interfaces()It was possible for two query interface works to be concurrently tryingto update the interfaces.Prevent this by checking and updating iface_last_update underiface_lock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:EFI/CPER: don't go past the ARM processor CPER record bufferThere's a logic inside GHES/CPER to detect if the section_lengthis too small, but it doesn't detect if it is too big.Currently, if the firmware receives an ARM processor CPER recordstating that a section length is big, kernel will blindly trustsection_length, producing a very long dump. For instance, a 67bytes record with ERR_INFO_NUM set 46198 and section lengthset to 854918320 would dump a lot of data going a way past thefirmware memory-mapped area.Fix it by adding a logic to prevent it to go past the bufferif ERR_INFO_NUM is too big, making it report instead: [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 [Hardware Error]: event severity: recoverable [Hardware Error]: Error 0, type: recoverable [Hardware Error]: section_type: ARM processor error [Hardware Error]: MIDR: 0xff304b2f8476870a [Hardware Error]: section length: 854918320, CPER size: 67 [Hardware Error]: section length is too big [Hardware Error]: firmware-generated error record is incorrect [Hardware Error]: ERR_INFO_NUM is 46198[ rjw: Subject and changelog tweaks ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-af: Workaround SQM/PSE stalls by disabling stickyNIX SQ manager sticky mode is known to cause stalls when multiple SQsshare an SMQ and transmit concurrently. Additionally, PSE may deadlockon transitions between sticky and non-sticky transmissions. There isalso a credit drop issue observed when certain condition clocks aregated.work around these hardware errata by:- Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14)- Disabling sticky -> non-sticky transition path that can deadlock PSE: - Clear TM5 (bit 23)- Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21)These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With thisconfiguration the SQM/PSE maintain forward progress under load withoutcredit loss, at the cost of disabling sticky optimizations.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/page_alloc: clear page->private in free_pages_prepare()Several subsystems (slub, shmem, ttm, etc.) use page->private but don'tclear it before freeing pages. When these pages are later allocated ashigh-order pages and split via split_page(), tail pages retain stalepage->private values.This causes a use-after-free in the swap subsystem. The swap code usespage->private to track swap count continuations, assuming freshlyallocated pages have page->private == 0. When stale values are present,swap_count_continued() incorrectly assumes the continuation list is validand iterates over uninitialized page->lru containing LIST_POISON values,causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860Fix this by clearing page->private in free_pages_prepare(), ensuring allfreed pages have clean state regardless of previous use.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: define and enforce CEPH_MAX_KEY_LENWhen decoding the key, verify that the key material would fit intoa fixed-size buffer in process_auth_done() and generally has a sanelength.The new CEPH_MAX_KEY_LEN check replaces the existing check for a keywith no key material which is a) not universal since CEPH_CRYPTO_NONEhas to be excluded and b) doesn't provide much value since a smallerthan needed key is just as invalid as no key -- this has to be handledelsewhere anyway.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: verisilicon: Avoid G2 bus error while decoding H.264 and HEVCFor the i.MX8MQ platform, there is a hardware limitation: the g1 VPU andg2 VPU cannot decode simultaneously; otherwise, it will cause below buserror and produce corrupted pictures, even potentially lead to system hang.[ 110.527986] hantro-vpu 38310000.video-codec: frame decode timed out.[ 110.583517] hantro-vpu 38310000.video-codec: bus error detected.Therefore, it is necessary to ensure that g1 and g2 operate alternately.This allows for successful multi-instance decoding of H.264 and HEVC.To achieve this, g1 and g2 share the same v4l2_m2m_dev, and then thev4l2_m2m_dev can handle the scheduling.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: ov5647: Initialize subdev before controlsIn ov5647_init_controls() we call v4l2_get_subdevdata, but it isinitialized by v4l2_i2c_subdev_init() in the probe, which currentlyhappens after init_controls(). This can result in a segfault if theerror condition is hit, and we try to access i2c_client, so fix theorder.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3() succeedingDrop the WARN in svm_set_nested_state() on nested_svm_load_cr3() failingas it is trivially easy to trigger from userspace by modifying CPUID afterloading CR3. E.g. modifying the state restoration selftest like so: --- tools/testing/selftests/kvm/x86/state_test.c +++ tools/testing/selftests/kvm/x86/state_test.c @@ -280,7 +280,16 @@ int main(int argc, char *argv[]) /* Restore state in a new VM. */ vcpu = vm_recreate_with_one_vcpu(vm); - vcpu_load_state(vcpu, state); + + if (stage == 4) { + state->sregs.cr3 = BIT(44); + vcpu_load_state(vcpu, state); + + vcpu_set_cpuid_property(vcpu, X86_PROPERTY_MAX_PHY_ADDR, 36); + __vcpu_nested_state_set(vcpu, &state->nested); + } else { + vcpu_load_state(vcpu, state); + } /* * Restore XSAVE state in a dummy vCPU, first without doinggenerates: WARNING: CPU: 30 PID: 938 at arch/x86/kvm/svm/nested.c:1877 svm_set_nested_state+0x34a/0x360 [kvm_amd] Modules linked in: kvm_amd kvm irqbypass [last unloaded: kvm] CPU: 30 UID: 1000 PID: 938 Comm: state_test Tainted: G W 6.18.0-rc7-58e10b63777d-next-vm Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_set_nested_state+0x34a/0x360 [kvm_amd] Call Trace: kvm_arch_vcpu_ioctl+0xf33/0x1700 [kvm] kvm_vcpu_ioctl+0x4e6/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x61/0xad0 entry_SYSCALL_64_after_hwframe+0x4b/0x53Simply delete the WARN instead of trying to prevent userspace from shoving"illegal" state into CR3. For better or worse, KVM's ABI allows userspaceto set CPUID after SREGS, and vice versa, and KVM is very permissive whenit comes to guest CPUID. I.e. attempting to enforce the virtual CPU modelwhen setting CPUID could break userspace. Given that the WARN doesn'tprovide any meaningful protection for KVM or benefit for userspace, simplydrop it even though the odds of breaking userspace are minuscule.Opportunistically delete a spurious newline.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:most: core: fix leak on early registration failureA recent commit fixed a resource leak on early registration failures butfor some reason left out the first error path which still leaks theresources associated with the interface.Fix up also the first error path so that the interface is alwaysreleased on errors.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix sync handling in amdgpu_dma_buf_move_notifyInvalidating a dmabuf will impact other users of the shared BO.In the scenario where process A moves the BO, it needs to informprocess B about the move and process B will need to update itspage table.The commit fixes a synchronisation bug caused by the use of theticket: it made amdgpu_vm_handle_moved behave as if updatingthe page table immediately was correct but in this case it's not.An example is the following scenario, with 2 GPUs and glxgearsrunning on GPU0 and Xorg running on GPU1, on a system where P2PPCI isn't supported:glxgears: export linear buffer from GPU0 and import using GPU1 submit frame rendering to GPU0 submit tiled->linear blitXorg: copy of linear bufferThe sequence of jobs would be: drm_sched_job_run # GPU0, frame rendering drm_sched_job_queue # GPU0, blit drm_sched_job_done # GPU0, frame rendering drm_sched_job_run # GPU0, blit move linear buffer for GPU1 access # amdgpu_dma_buf_move_notify -> update pt # GPU0It this point the blit job on GPU0 is still running and wouldlikely produce a page fault.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: dummy-hcd: Fix interrupt synchronization errorThis fixes an error in synchronization in the dummy-hcd driver. Theerror has a somewhat involved history. The synchronization mechanismwas introduced by commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneoussynchronization change"), which added an emulated "interrupts enabled"flag together with code emulating synchronize_irq() (it waits untilall current handler callbacks have returned).But the emulated interrupt-disable occurred too late, after the drivercontaining the handler callback routines had been told that it wasunbound and no more callbacks would occur. Commit 4a5d797a9f9c ("usb:gadget: dummy_hcd: fix gpf in gadget_setup") tried to fix this bymoving the synchronize_irq() emulation code from dummy_stop() todummy_pullup(), which runs before the unbind callback.There still were races, though, because the emulated interrupt-disablestill occurred too late. It couldn't be moved to dummy_pullup(),because that routine can be called for reasons other than an impendingunbind. Therefore commits 7dc0c55e9f30 ("USB: UDC core: Addudc_async_callbacks gadget op") and 04145a03db9d ("USB: UDC: Implementudc_async_callbacks in dummy-hcd") added an API allowing the UDC coreto tell dummy-hcd exactly when emulated interrupts and their callbacksshould be disabled.That brings us to the current state of things, which is still wrongbecause the emulated synchronize_irq() occurs before the emulatedinterrupt-disable! That's no good, beause it means that more emulatedinterrupts can occur after the synchronize_irq() emulation has run,leading to the possibility that a callback handler may be running whenthe gadget driver is unbound.To fix this, we have to move the synchronize_irq() emulation code yetagain, to the dummy_udc_async_callbacks() routine, which takes care ofenabling and disabling emulated interrupt requests. Thesynchronization will now run immediately after emulated interrupts aredisabled, which is where it belongs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: dummy-hcd: Fix locking/synchronization errorSyzbot testing was able to provoke an addressing exception and crashin the usb_gadget_udc_reset() routine indrivers/usb/gadgets/udc/core.c, resulting from the fact that theroutine was called with a second ("driver") argument of NULL. The badcaller was set_link_state() in dummy_hcd.c, and the problem arosebecause of a race between a USB reset and driver unbind.These sorts of races were not supposed to be possible; commit7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"),along with a few followup commits, was written specifically to preventthem. As it turns out, there are (at least) two errors remaining inthe code. Another patch will address the second error; this one isconcerned with the first.The error responsible for the syzbot crash occurred because thestop_activity() routine will sometimes drop and then re-acquire thedum->lock spinlock. A call to stop_activity() occurs inset_link_state() when handling an emulated USB reset, after the testof dum->ints_enabled and before the increment of dum->callback_usage.This allowed another thread (doing a driver unbind) to sneak in andgrab the spinlock, and then clear dum->ints_enabled and dum->driver.Normally this other thread would have to wait for dum->callback_usageto go down to 0 before it would clear dum->driver, but in this case itdidn't have to wait since dum->callback_usage had not yet beenincremented.The fix is to increment dum->callback_usage _before_ callingstop_activity() instead of after. Then the thread doing the unbindwill not clear dum->driver until after the call tousb_gadget_udc_reset() safely returns and dum->callback_usage has beendecremented again.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_rndis: Protect RNDIS options with mutexThe class/subclass/protocol options are suspectible to race conditionsas they can be accessed concurrently through configfs.Use existing mutex to protect these options. This issue was identifiedduring code inspection.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i3c: mipi-i3c-hci: Correct RING_CTRL_ABORT handling in DMA dequeueThe logic used to abort the DMA ring contains several flaws: 1. The driver unconditionally issues a ring abort even when the ring has already stopped. 2. The completion used to wait for abort completion is never re-initialized, resulting in incorrect wait behavior. 3. The abort sequence unintentionally clears RING_CTRL_ENABLE, which resets hardware ring pointers and disrupts the controller state. 4. If the ring is already stopped, the abort operation should be considered successful without attempting further action.Fix the abort handling by checking whether the ring is running beforeissuing an abort, re-initializing the completion when needed, ensuring thatRING_CTRL_ENABLE remains asserted during abort, and treating an alreadystopped ring as a successful condition.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs readThe q54sj108a2_debugfs_read function suffers from a stack buffer overflowdue to incorrect arguments passed to bin2hex(). The function currentlypasses 'data' as the destination and 'data_char' as the source.Because bin2hex() converts each input byte into two hex characters, a32-byte block read results in 64 bytes of output. Since 'data' is only34 bytes (I2C_SMBUS_BLOCK_MAX + 2), this writes 30 bytes past the endof the buffer onto the stack.Additionally, the arguments were swapped: it was reading from thezero-initialized 'data_char' and writing to 'data', resulting inall-zero output regardless of the actual I2C read.Fix this by:1. Expanding 'data_char' to 66 bytes to safely hold the hex output.2. Correcting the bin2hex() argument order and using the actual read count.3. Using a pointer to select the correct output buffer for the final simple_read_from_buffer call.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: Use u32 for non-negative values in ceph_monmap_decode()This patch fixes unnecessary implicit conversions that change signednessof blob_len and num_mon in ceph_monmap_decode().Currently blob_len and num_mon are (signed) int variables. They are usedto hold values that are always non-negative and get assigned inceph_decode_32_safe(), which is meant to assign u32 values. Bothvariables are subsequently used as unsigned values, and the value ofnum_mon is further assigned to monmap->num_mon, which is of type u32.Therefore, both variables should be of type u32. This is especiallyrelevant for num_mon. If the value read from the incoming message isvery large, it is interpreted as a negative value, and the check fornum_mon > CEPH_MAX_MON does not catch it. This leads to the attempt toallocate a very large chunk of memory for monmap, which will most likelyfail. In this case, an unnecessary attempt to allocate memory isperformed, and -ENOMEM is returned instead of -EINVAL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: prevent potential out-of-bounds reads in process_message_header()If the message frame is (maliciously) corrupted in a way that thelength of the control segment ends up being less than the size of themessage header or a different frame is made to look like a messageframe, out-of-bounds reads may ensue in process_message_header().Perform an explicit bounds check before decoding the message header.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix i_nlink underrun during async unlinkDuring async unlink, we drop the `i_nlink` counter before we receivethe completion (that will eventually update the `i_nlink`) because "weassume that the unlink will succeed". That is not a bad idea, but itraces against deletions by other clients (or against the completion ofour own unlink) and can lead to an underrun which emits a WARNING likethis one: WARNING: CPU: 85 PID: 25093 at fs/inode.c:407 drop_nlink+0x50/0x68 Modules linked in: CPU: 85 UID: 3221252029 PID: 25093 Comm: php-cgi8.1 Not tainted 6.14.11-cm4all1-ampere #655 Hardware name: Supermicro ARS-110M-NR/R12SPD-A, BIOS 1.1b 10/17/2023 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drop_nlink+0x50/0x68 lr : ceph_unlink+0x6c4/0x720 sp : ffff80012173bc90 x29: ffff80012173bc90 x28: ffff086d0a45aaf8 x27: ffff0871d0eb5680 x26: ffff087f2a64a718 x25: 0000020000000180 x24: 0000000061c88647 x23: 0000000000000002 x22: ffff07ff9236d800 x21: 0000000000001203 x20: ffff07ff9237b000 x19: ffff088b8296afc0 x18: 00000000f3c93365 x17: 0000000000070000 x16: ffff08faffcbdfe8 x15: ffff08faffcbdfec x14: 0000000000000000 x13: 45445f65645f3037 x12: 34385f6369706f74 x11: 0000a2653104bb20 x10: ffffd85f26d73290 x9 : ffffd85f25664f94 x8 : 00000000000000c0 x7 : 0000000000000000 x6 : 0000000000000002 x5 : 0000000000000081 x4 : 0000000000000481 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff08727d3f91e8 Call trace: drop_nlink+0x50/0x68 (P) vfs_unlink+0xb0/0x2e8 do_unlinkat+0x204/0x288 __arm64_sys_unlinkat+0x3c/0x80 invoke_syscall.constprop.0+0x54/0xe8 do_el0_svc+0xa4/0xc8 el0_svc+0x18/0x58 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x154/0x158In ceph_unlink(), a call to ceph_mdsc_submit_request() submits theCEPH_MDS_OP_UNLINK to the MDS, but does not wait for completion.Meanwhile, between this call and the following drop_nlink() call, aworker thread may process a CEPH_CAP_OP_IMPORT, CEPH_CAP_OP_GRANT orjust a CEPH_MSG_CLIENT_REPLY (the latter of which could be our owncompletion). These will lead to a set_nlink() call, updating the`i_nlink` counter to the value received from the MDS. If that new`i_nlink` value happens to be zero, it is illegal to decrement itfurther. But that is exactly what ceph_unlink() will do then.The WARNING can be reproduced this way:1. Force async unlink; only the async code path is affected. Having no real clue about Ceph internals, I was unable to find out why the MDS wouldn't give me the "Fxr" capabilities, so I patched get_caps_for_async_unlink() to always succeed. (Note that the WARNING dump above was found on an unpatched kernel, without this kludge - this is not a theoretical bug.)2. Add a sleep call after ceph_mdsc_submit_request() so the unlink completion gets handled by a worker thread before drop_nlink() is called. This guarantees that the `i_nlink` is already zero before drop_nlink() runs.The solution is to skip the counter decrement when it is already zero,but doing so without a lock is still racy (TOCTOU). Sinceceph_fill_inode() and handle_cap_grant() both hold the`ceph_inode_info.i_ceph_lock` spinlock while set_nlink() runs, thisseems like the proper lock to protect the `i_nlink` updates.I found prior art in NFS and SMB (using `inode.i_lock`) and AFS (using`afs_vnode.cb_lock`). All three have the zero check as well.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: usbtmc: Use usb_bulk_msg_killable() with user-specified timeoutsThe usbtmc driver accepts timeout values specified by the user in anioctl command, and uses these timeouts for some usb_bulk_msg() calls.Since the user can specify arbitrarily long timeouts andusb_bulk_msg() uses unkillable waits, call usb_bulk_msg_killable()instead to avoid the possibility of the user hanging a kernel threadindefinitely.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: xhci: Fix memory leak in xhci_disable_slot()xhci_alloc_command() allocates a command structure and, when thesecond argument is true, also allocates a completion structure.Currently, the error handling path in xhci_disable_slot() only freesthe command structure using kfree(), causing the completion structureto leak.Use xhci_free_command() instead of kfree(). xhci_free_command() correctlyfrees both the command structure and the associated completion structure.Since the command structure is allocated with zero-initialization,command->in_ctx is NULL and will not be erroneously freed byxhci_free_command().This bug was found using an experimental static analysis tool we aredeveloping. The tool is based on the LLVM framework and is specificallydesigned to detect memory management issues. It is currently underactive development and not yet publicly available, but we plan toopen-source it after our research is published.The bug was originally detected on v6.13-rc1 using our static analysistool, and we have verified that the issue persists in the latest mainlinekernel.We performed build testing on x86_64 with allyesconfig using GCC=11.4.0.Since triggering these error paths in xhci_disable_slot() requires specifichardware conditions or abnormal state, we were unable to construct a testcase to reliably trigger these specific error paths at runtime.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Check endpoint numbers at parsing Scarlett2 mixer interfacesThe Scarlett2 mixer quirk in USB-audio driver may hit a NULLdereference when a malformed USB descriptor is passed, since itassumes the presence of an endpoint in the parsed interface inscarlett2_find_fc_interface(), as reported by fuzzer.For avoiding the NULL dereference, just add the sanity check ofbNumEndpoints and skip the invalid interface.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cgroup: fix race between task migration and iterationWhen a task is migrated out of a css_set, cgroup_migrate_add_task()first moves it from cset->tasks to cset->mg_tasks via: list_move_tail(&task->cg_list, &cset->mg_tasks);If a css_task_iter currently has it->task_pos pointing to this task,css_set_move_task() calls css_task_iter_skip() to keep the iteratorvalid. However, since the task has already been moved to ->mg_tasks,the iterator is advanced relative to the mg_tasks list instead of theoriginal tasks list. As a result, remaining tasks on cset->tasks, aswell as tasks queued on cset->mg_tasks, can be skipped by iteration.Fix this by calling css_set_skip_task_iters() before unlinkingtask->cg_list from cset->tasks. This advances all active iterators tothe next task on cset->tasks, so iteration continues correctly evenwhen a task is concurrently being migrated.This race is hard to hit in practice without instrumentation, but itcan be reproduced by artificially slowing down cgroup_procs_show().For example, on an Android device a temporary/sys/kernel/cgroup/cgroup_test knob can be added to inject a delayinto cgroup_procs_show(), and then: 1) Spawn three long-running tasks (PIDs 101, 102, 103). 2) Create a test cgroup and move the tasks into it. 3) Enable a large delay via /sys/kernel/cgroup/cgroup_test. 4) In one shell, read cgroup.procs from the test cgroup. 5) Within the delay window, in another shell migrate PID 102 by writing it to a different cgroup.procs file.Under this setup, cgroup.procs can intermittently show only PID 101while skipping PID 103. Once the migration completes, reading thefile again shows all tasks as expected.Note that this change does not allow removing the existingcss_set_skip_task_iters() call in css_set_move_task(). The new callin cgroup_migrate_add_task() only handles iterators that are racingwith migration while the task is still on cset->tasks. Iterators mayalso start after the task has been moved to cset->mg_tasks. If wedropped css_set_skip_task_iters() from css_set_move_task(), suchiterators could keep task_pos pointing to a migrating task, causingcss_task_iter_advance() to malfunction on the destination css_set,up to and including crashes or infinite loops.The race window between migration and iteration is very small, andcss_task_iter is not on a hot path. In the worst case, when aniterator is positioned on the first thread of the migrating process,cgroup_migrate_add_task() may have to skip multiple tasks viacss_set_skip_task_iters(). However, this only happens when migrationand iteration actually race, so the performance impact is negligiblecompared to the correctness fix provided here.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: amd: acp-mach-common: Add missing error check for clock acquisitionThe acp_card_rt5682_init() and acp_card_rt5682s_init() functions did notcheck the return values of clk_get(). This could lead to a kernel crashwhen the invalid pointers are later dereferenced by clock corefunctions.Fix this by:1. Changing clk_get() to the device-managed devm_clk_get().2. Adding IS_ERR() checks immediately after each clock acquisition.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: Fix race bug in nvme_poll_irqdisable()In the following scenario, pdev can be disabled between (1) and (3) by(2). This sets pdev->msix_enabled = 0. Then, pci_irq_vector() willreturn MSI-X IRQ(>15) for (1) whereas return INTx IRQ(<=15) for (2).This causes IRQ warning because it tries to enable INTx IRQ that hasnever been disabled before.To fix this, save IRQ number into a local variable and ensuredisable_irq() and enable_irq() operate on the same IRQ number. Even ifpci_free_irq_vectors() frees the IRQ concurrently, disable_irq() andenable_irq() on a stale IRQ number is still valid and safe, and thedepth accounting reamins balanced.task 1:nvme_poll_irqdisable() disable_irq(pci_irq_vector(pdev, nvmeq->cq_vector)) ...(1) enable_irq(pci_irq_vector(pdev, nvmeq->cq_vector)) ...(3)task 2:nvme_reset_work() nvme_dev_disable() pdev->msix_enable = 0; ...(2)crash log:------------[ cut here ]------------Unbalanced enable for IRQ 10WARNING: kernel/irq/manage.c:753 at __enable_irq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26Modules linked in:CPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014Workqueue: kblockd blk_mq_timeout_workRIP: 0010:__enable_irq+0x107/0x190 kernel/irq/manage.c:753Code: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c <67> 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9RSP: 0018:ffffc900001bf550 EFLAGS: 00010046RAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90RDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0RBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001R10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000R13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293FS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0Call Trace: enable_irq+0x121/0x1e0 kernel/irq/manage.c:797 nvme_poll_irqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494 nvme_timeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744 blk_mq_rq_timed_out block/blk-mq.c:1653 [inline] blk_mq_handle_expired+0x227/0x2d0 block/blk-mq.c:1721 bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c:292 __sbitmap_for_each_set include/linux/sbitmap.h:269 [inline] sbitmap_for_each_set include/linux/sbitmap.h:290 [inline] bt_for_each block/blk-mq-tag.c:324 [inline] blk_mq_queue_tag_busy_iter+0x969/0x1e80 block/blk-mq-tag.c:536 blk_mq_timeout_work+0x627/0x870 block/blk-mq.c:1763 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 irq event stamp: 74478hardirqs last enabled at (74477): [] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:159 [inline]hardirqs last enabled at (74477): [] _raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c:202hardirqs last disabled at (74478): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]hardirqs last disabled at (74478): [] _raw_spin_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:162softirqs last enabled at (74304): [] __do_softirq kernel/softirq.c:656 [inline]softirqs last enabled at (74304): [] invoke_softirq kernel/softirq.c:496 [inline]softirqs last enabled at (74304): [] __irq_exit_rcu+0xdc/0x120---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: fix stack out-of-bounds read in pipapo_drop()pipapo_drop() passes rulemap[i + 1].n to pipapo_unmap() as theto_offset argument on every iteration, including the last one wherei == m->field_count - 1. This reads one element past the end of thestack-allocated rulemap array (declared as rulemap[NFT_PIPAPO_MAX_FIELDS]with NFT_PIPAPO_MAX_FIELDS == 16).Although pipapo_unmap() returns early when is_last is true withoutusing the to_offset value, the argument is evaluated at the call sitebefore the function body executes, making this a genuine out-of-boundsstack read confirmed by KASAN: BUG: KASAN: stack-out-of-bounds in pipapo_drop+0x50c/0x57c [nf_tables] Read of size 4 at addr ffff8000810e71a4 This frame has 1 object: [32, 160) 'rulemap' The buggy address is at offset 164 -- exactly 4 bytes past the end of the rulemap array.Pass 0 instead of rulemap[i + 1].n on the last iteration to avoidthe out-of-bounds read.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: soc-core: flush delayed work before removing DAIs and widgetsWhen a sound card is unbound while a PCM stream is open, ause-after-free can occur in snd_soc_dapm_stream_event(), called fromthe close_delayed_work workqueue handler.During unbind, snd_soc_unbind_card() flushes delayed work and thencalls soc_cleanup_card_resources(). Inside cleanup,snd_card_disconnect_sync() releases all PCM file descriptors, andthe resulting PCM close path can call snd_soc_dapm_stream_stop()which schedules new delayed work with a pmdown_time timer delay.Since this happens after the flush in snd_soc_unbind_card(), thenew work is not caught. soc_remove_link_components() then freesDAPM widgets before this work fires, leading to the use-after-free.The existing flush in soc_free_pcm_runtime() also cannot help as itruns after soc_remove_link_components() has already freed the widgets.Add a flush in soc_cleanup_card_resources() aftersnd_card_disconnect_sync() (after which no new PCM closes canschedule further delayed work) and before soc_remove_link_dais()and soc_remove_link_components() (which tear down the structures thedelayed work accesses).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix deadlock between devlink lock and esw->wqesw->work_queue executes esw_functions_changed_event_handler ->esw_vfs_changed_event_handler and acquires the devlink lock..eswitch_mode_set (acquires devlink lock in devlink_nl_pre_doit) ->mlx5_devlink_eswitch_mode_set -> mlx5_eswitch_disable_locked ->mlx5_eswitch_event_handler_unregister -> flush_workqueue deadlockswhen esw_vfs_changed_event_handler executes.Fix that by no longer flushing the work to avoid the deadlock, and usinga generation counter to keep track of work relevance. This avoids an oldhandler manipulating an esw that has undergone one or more mode changes:- the counter is incremented in mlx5_eswitch_event_handler_unregister.- the counter is read and passed to the ephemeral mlx5_host_work struct.- the work handler takes the devlink lock and bails out if the current generation is different than the one it was scheduled to operate on.- mlx5_eswitch_cleanup does the final draining before destroying the wq.No longer flushing the workqueue has the side effect of maybe no longercancelling pending vport_change_handler work items, but that's ok sincethose are disabled elsewhere:- mlx5_eswitch_disable_locked disables the vport eq notifier.- mlx5_esw_vport_disable disarms the HW EQ notification and marks vport->enabled under state_lock to false to prevent pending vport handler from doing anything.- mlx5_eswitch_cleanup destroys the workqueue and makes sure all events are disabled/finished.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xprtrdma: Decrement re_receiving on the early exit pathsIn the event that rpcrdma_post_recvs() fails to create a work request(due to memory allocation failure, say) or otherwise exits early, weshould decrement ep->re_receiving before returning. Otherwise we willhang in rpcrdma_xprt_drain() as re_receiving will never reach zero andthe completion will never be triggered.On a system with high memory pressure, this can appear as the followinghung task: INFO: task kworker/u385:17:8393 blocked for more than 122 seconds. Tainted: G S E 6.19.0 #3 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u385:17 state:D stack:0 pid:8393 tgid:8393 ppid:2 task_flags:0x4248060 flags:0x00080000 Workqueue: xprtiod xprt_autoclose [sunrpc] Call Trace: __schedule+0x48b/0x18b0 ? ib_post_send_mad+0x247/0xae0 [ib_core] schedule+0x27/0xf0 schedule_timeout+0x104/0x110 __wait_for_common+0x98/0x180 ? __pfx_schedule_timeout+0x10/0x10 wait_for_completion+0x24/0x40 rpcrdma_xprt_disconnect+0x444/0x460 [rpcrdma] xprt_rdma_close+0x12/0x40 [rpcrdma] xprt_autoclose+0x5f/0x120 [sunrpc] process_one_work+0x191/0x3e0 worker_thread+0x2e3/0x420 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x273/0x2b0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpi3mr: Add NULL checks when resetting request and reply queuesThe driver encountered a crash during resource cleanup when the reply andrequest queues were NULL due to freed memory. This issue occurred when thecreation of reply or request queues failed, and the driver freed the memoryfirst, but attempted to mem set the content of the freed memory, leading toa system crash.Add NULL pointer checks for reply and request queues before accessing thereply/request memory during cleanup
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: chemical: sps30_i2c: fix buffer size in sps30_i2c_read_meas()sizeof(num) evaluates to sizeof(size_t) (8 bytes on 64-bit) insteadof the intended __be32 element size (4 bytes). Use sizeof(*meas) tocorrectly match the buffer element type.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock acquisitionThe acp3x_5682_init() function did not check the return value ofclk_get(), which could lead to dereferencing error pointers inrt5682_clk_enable().Fix this by:1. Changing clk_get() to the device-managed devm_clk_get().2. Adding proper IS_ERR() checks for both clock acquisitions.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: jq is a command-line JSON processor. In 1.8.1 and earlier, unbounded recursion in jv_object_merge_recursive() allows a crafted jq program to crash the process with a segfault. The function is reachable through the * operator when both operands are objects.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.1).
-
Description: jq is a command-line JSON processor. In 1.8.2rc1 and earlier, the ordinary module loader recurses without cycle detection when twootherwise valid modules include each other.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- tar > 0-0 (version in image is 1.34-150000.3.37.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libefivar1 > 0-0 (version in image is 37-6.12.1).
-
Description: ping in iputils before 20250602 allows a denial of service (application error in adaptive ping mode or incorrect data collection) via a crafted ICMP Echo Reply packet, because a zero timestamp can lead to large intermediate values that have an integer overflow when squared during statistics calculations. NOTE: this issue exists because of an incomplete fix for CVE-2025-47268 (that fix was only about timestamp calculations, and it did not account for a specific scenario where the original timestamp in the ICMP payload is zero).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- iputils > 0-0 (version in image is 20221126-150500.3.14.1).
-
Description: An integer overflow exists in the FTS5 https://sqlite.org/fts5.html extension. It occurs when the size of an array of tombstone pointers is calculated and truncated into a 32-bit integer. A pointer to partially controlled data can then be written out of bounds.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libsqlite3-0 > 0-0 (version in image is 3.51.3-150000.3.39.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: avoid double ->queue_rq() because of early timeoutDavid Jeffery found one double ->queue_rq() issue, so far it canbe triggered in VM use case because of long vmexit latency or preemptlatency of vCPU pthread or long page fault in vCPU pthread, then blockIO req could be timed out before queuing the request to hardware but aftercalling blk_mq_start_request() during ->queue_rq(), then timeout handlermay handle it by requeue, then double ->queue_rq() is caused, and kernelpanic.So far, it is driver's responsibility to cover the race between timeoutand completion, so it seems supposed to be solved in driver in theory,given driver has enough knowledge.But it is really one common problem, lots of driver could have similarissue, and could be hard to fix all affected drivers, even it isn't easyfor driver to handle the race. So David suggests this patch by drainingin-progress ->queue_rq() for solving this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: use proper req destructor for IPv6Before, only the destructor from TCP request sock in IPv4 was calledeven if the subflow was IPv6.It is important to use the right destructor to avoid memory leaks withsome advanced IPv6 features, e.g. when the request socks containspecific IPv6 options.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hsr: avoid possible NULL deref in skb_clone()syzbot got a crash [1] in skb_clone(), caused by a bugin hsr_get_untagged_frame().When/if create_stripped_skb_hsr() returns NULL, we mustnot attempt to call skb_clone().While we are at it, replace a WARN_ONCE() by netdev_warn_once().[1]general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]CPU: 1 PID: 754 Comm: syz-executor.0 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022RIP: 0010:skb_clone+0x108/0x3c0 net/core/skbuff.c:1641Code: 93 02 00 00 49 83 7c 24 28 00 0f 85 e9 00 00 00 e8 5d 4a 29 fa 4c 8d 75 7e 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 4c 89 f2 83 e2 07 38 d0 7f 08 84 c0 0f 85 9e 01 00 00RSP: 0018:ffffc90003ccf4e0 EFLAGS: 00010207RAX: dffffc0000000000 RBX: ffffc90003ccf5f8 RCX: ffffc9000c24b000RDX: 000000000000000f RSI: ffffffff8751cb13 RDI: 0000000000000000RBP: 0000000000000000 R08: 00000000000000f0 R09: 0000000000000140R10: fffffbfff181d972 R11: 0000000000000000 R12: ffff888161fc3640R13: 0000000000000a20 R14: 000000000000007e R15: ffffffff8dc5f620FS: 00007feb621e4700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007feb621e3ff8 CR3: 00000001643a9000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:hsr_get_untagged_frame+0x4e/0x610 net/hsr/hsr_forward.c:164hsr_forward_do net/hsr/hsr_forward.c:461 [inline]hsr_forward_skb+0xcca/0x1d50 net/hsr/hsr_forward.c:623hsr_handle_frame+0x588/0x7c0 net/hsr/hsr_slave.c:69__netif_receive_skb_core+0x9fe/0x38f0 net/core/dev.c:5379__netif_receive_skb_one_core+0xae/0x180 net/core/dev.c:5483__netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5599netif_receive_skb_internal net/core/dev.c:5685 [inline]netif_receive_skb+0x12f/0x8d0 net/core/dev.c:5744tun_rx_batched+0x4ab/0x7a0 drivers/net/tun.c:1544tun_get_user+0x2686/0x3a00 drivers/net/tun.c:1995tun_chr_write_iter+0xdb/0x200 drivers/net/tun.c:2025call_write_iter include/linux/fs.h:2187 [inline]new_sync_write fs/read_write.c:491 [inline]vfs_write+0x9e9/0xdd0 fs/read_write.c:584ksys_write+0x127/0x250 fs/read_write.c:637do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bcmgenet: Add a check for oversized packetsOccasionnaly we may get oversized packets from the hardware whichexceed the nomimal 2KiB buffer size we allocate SKBs with. Add an earlycheck which drops the packet to avoid invoking skb_over_panic() and moveon to processing the next packet.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:posix-timers: Ensure timer ID search-loop limit is validposix_timer_add() tries to allocate a posix timer ID by starting from thecached ID which was stored by the last successful allocation.This is done in a loop searching the ID space for a free slot one byone. The loop has to terminate when the search wrapped around to thestarting point.But that's racy vs. establishing the starting point. That is read outlockless, which leads to the following problem:CPU0 CPU1posix_timer_add() start = sig->posix_timer_id; lock(hash_lock); ... posix_timer_add() if (++sig->posix_timer_id < 0) start = sig->posix_timer_id; sig->posix_timer_id = 0;So CPU1 can observe a negative start value, i.e. -1, and the loop breaknever happens because the condition can never be true: if (sig->posix_timer_id == start) break;While this is unlikely to ever turn into an endless loop as the ID space ishuge (INT_MAX), the racy read of the start value caught the attention ofKCSAN and Dmitry unearthed that incorrectness.Rewrite it so that all id operations are under the hash lock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dccp: Fix out of bounds access in DCCP error handlerThere was a previous attempt to fix an out-of-bounds access in the DCCPerror handlers, but that fix assumed that the error handlers only wantto access the first 8 bytes of the DCCP header. Actually, they also lookat the DCCP sequence number, which is stored beyond 8 bytes, so anexplicit pskb_may_pull() is required.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.56.1).
-
Description: A flaw was found in Avahi-daemon, which relies on fixed source ports for wide-area DNS queries. This issue simplifies attacks where malicious DNS responses are injected.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- libavahi-client3 > 0-0 (version in image is 0.8-150400.7.26.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix receive ring space parameters when XDP is activeThe MTU setting at the time an XDP multi-buffer is attacheddetermines whether the aggregation ring will be used and therx_skb_func handler. This is done in bnxt_set_rx_skb_mode().If the MTU is later changed, the aggregation ring setting may needto be changed and it may become out-of-sync with the settingsinitially done in bnxt_set_rx_skb_mode(). This may result inrandom memory corruption and crashes as the HW may DMA data largerthan the allocated buffer size, such as:BUG: kernel NULL pointer dereference, address: 00000000000003c0PGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMP NOPTICPU: 17 PID: 0 Comm: swapper/17 Kdump: loaded Tainted: G S OE 6.1.0-226bf9805506 #1Hardware name: Wiwynn Delta Lake PVT BZA.02601.0150/Delta Lake-Class1, BIOS F0E_3A12 08/26/2021RIP: 0010:bnxt_rx_pkt+0xe97/0x1ae0 [bnxt_en]Code: 8b 95 70 ff ff ff 4c 8b 9d 48 ff ff ff 66 41 89 87 b4 00 00 00 e9 0b f7 ff ff 0f b7 43 0a 49 8b 95 a8 04 00 00 25 ff 0f 00 00 <0f> b7 14 42 48 c1 e2 06 49 03 95 a0 04 00 00 0f b6 42 33fRSP: 0018:ffffa19f40cc0d18 EFLAGS: 00010202RAX: 00000000000001e0 RBX: ffff8e2c805c6100 RCX: 00000000000007ffRDX: 0000000000000000 RSI: ffff8e2c271ab990 RDI: ffff8e2c84f12380RBP: ffffa19f40cc0e48 R08: 000000000001000d R09: 974ea2fcddfa4cbfR10: 0000000000000000 R11: ffffa19f40cc0ff8 R12: ffff8e2c94b58980R13: ffff8e2c952d6600 R14: 0000000000000016 R15: ffff8e2c271ab990FS: 0000000000000000(0000) GS:ffff8e3b3f840000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000000003c0 CR3: 0000000e8580a004 CR4: 00000000007706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: __bnxt_poll_work+0x1c2/0x3e0 [bnxt_en]To address the issue, we now call bnxt_set_rx_skb_mode() withinbnxt_change_mtu() to properly set the AGG rings configuration andupdate rx_skb_func based on the new MTU value.Additionally, BNXT_FLAG_NO_AGG_RINGS is cleared at the beginning ofbnxt_set_rx_skb_mode() to make sure it gets set or cleared based onthe current MTU.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix shift-out-of-bounds in dbSplitWhen dmt_budmin is less than zero, it causes errorsin the later stages. Added a check to return an error beforehandin dbAllocCtl itself.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:geneve: do not assume mac header is set in geneve_xmit_skb()We should not assume mac header is set in output path.Use skb_eth_hdr() instead of eth_hdr() to fix the issue.sysbot reported the following : WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 skb_mac_header include/linux/skbuff.h:3052 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 eth_hdr include/linux/if_ether.h:24 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit_skb drivers/net/geneve.c:898 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039Modules linked in:CPU: 0 UID: 0 PID: 11635 Comm: syz.4.1423 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_mac_header include/linux/skbuff.h:3052 [inline] RIP: 0010:eth_hdr include/linux/if_ether.h:24 [inline] RIP: 0010:geneve_xmit_skb drivers/net/geneve.c:898 [inline] RIP: 0010:geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039Code: 21 c6 02 e9 35 d4 ff ff e8 a5 48 4c fb 90 0f 0b 90 e9 fd f5 ff ff e8 97 48 4c fb 90 0f 0b 90 e9 d8 f5 ff ff e8 89 48 4c fb 90 <0f> 0b 90 e9 41 e4 ff ff e8 7b 48 4c fb 90 0f 0b 90 e9 cd e7 ff ffRSP: 0018:ffffc90003b2f870 EFLAGS: 00010283RAX: 000000000000037a RBX: 000000000000ffff RCX: ffffc9000dc3d000RDX: 0000000000080000 RSI: ffffffff86428417 RDI: 0000000000000003RBP: ffffc90003b2f9f0 R08: 0000000000000003 R09: 000000000000ffffR10: 000000000000ffff R11: 0000000000000002 R12: ffff88806603c000R13: 0000000000000000 R14: ffff8880685b2780 R15: 0000000000000e23FS: 00007fdc2deed6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b30a1dff8 CR3: 0000000056b8c000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] __dev_direct_xmit+0x58a/0x720 net/core/dev.c:4490 dev_direct_xmit include/linux/netdevice.h:3181 [inline] packet_xmit+0x1e4/0x360 net/packet/af_packet.c:285 packet_snd net/packet/af_packet.c:3146 [inline] packet_sendmsg+0x2700/0x5660 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg net/socket.c:726 [inline] __sys_sendto+0x488/0x4f0 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0xe0/0x1c0 net/socket.c:2200 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: bcm - add error check in the ahash_hmac_init functionThe ahash_init functions may return fails. The ahash_hmac_init shouldnot return ok when ahash_init returns error. For an example, ahash_initwill return -ENOMEM when allocation memory is error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transferperforms a cross-protocol redirect to a second URL that uses an IMAP, LDAP,POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the newtarget host.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- curl > 0-0 (version in image is 8.14.1-150400.5.83.1).
-
Description: When doing TLS related transfers with reused easy or multi handles andaltering the `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentallyreuse a CA store cached in memory for which the partial chain option wasreversed. Contrary to the user's wishes and expectations. This could makelibcurl find and accept a trust chain that it otherwise would not.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- curl > 0-0 (version in image is 8.14.1-150400.5.83.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.56.1).
-
Description: When doing SSH-based transfers using either SCP or SFTP, and setting theknown_hosts file, libcurl could still mistakenly accept connecting to hosts*not present* in the specified file if they were added as recognized in thelibssh *global* known_hosts file.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- curl > 0-0 (version in image is 8.14.1-150400.5.83.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: cls_flow: validate TCA_FLOW_RSHIFT attributesyzbot found that TCA_FLOW_RSHIFT attribute was not validated.Right shitfing a 32bit integer is undefined for large shift values.UBSAN: shift-out-of-bounds in net/sched/cls_flow.c:329:23shift exponent 9445 is too large for 32-bit type 'u32' (aka 'unsigned int')CPU: 1 UID: 0 PID: 54 Comm: kworker/u8:3 Not tainted 6.13.0-rc3-syzkaller-00180-g4f619d518db9 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: ipv6_addrconf addrconf_dad_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468 flow_classify+0x24d5/0x25b0 net/sched/cls_flow.c:329 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1771 [inline] tcf_classify+0x420/0x1160 net/sched/cls_api.c:1867 sfb_classify net/sched/sch_sfb.c:260 [inline] sfb_enqueue+0x3ad/0x18b0 net/sched/sch_sfb.c:318 dev_qdisc_enqueue+0x4b/0x290 net/core/dev.c:3793 __dev_xmit_skb net/core/dev.c:3889 [inline] __dev_queue_xmit+0xf0e/0x3f50 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 iptunnel_xmit+0x55d/0x9b0 net/ipv4/ip_tunnel_core.c:82 udp_tunnel_xmit_skb+0x262/0x3b0 net/ipv4/udp_tunnel_core.c:173 geneve_xmit_skb drivers/net/geneve.c:916 [inline] geneve_xmit+0x21dc/0x2d00 drivers/net/geneve.c:1039 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x27a/0x7d0 net/core/dev.c:3606 __dev_queue_xmit+0x1b73/0x3f50 net/core/dev.c:4434
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eth: bnxt: fix truesize for mb-xdp-pass caseWhen mb-xdp is set and return is XDP_PASS, packet is converted fromxdp_buff to sk_buff with xdp_update_skb_shared_info() inbnxt_xdp_build_skb().bnxt_xdp_build_skb() passes incorrect truesize argument toxdp_update_skb_shared_info().The truesize is calculated as BNXT_RX_PAGE_SIZE * sinfo->nr_frags butthe skb_shared_info was wiped by napi_build_skb() before.So it stores sinfo->nr_frags before bnxt_xdp_build_skb() and use itinstead of getting skb_shared_info from xdp_get_shared_info_from_buff().Splat looks like: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 0 at net/core/skbuff.c:6072 skb_try_coalesce+0x504/0x590 Modules linked in: xt_nat xt_tcpudp veth af_packet xt_conntrack nft_chain_nat xt_MASQUERADE nf_conntrack_netlink xfrm_user xt_addrtype nft_coms CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.14.0-rc2+ #3 RIP: 0010:skb_try_coalesce+0x504/0x590 Code: 4b fd ff ff 49 8b 34 24 40 80 e6 40 0f 84 3d fd ff ff 49 8b 74 24 48 40 f6 c6 01 0f 84 2e fd ff ff 48 8d 4e ff e9 25 fd ff ff <0f> 0b e99 RSP: 0018:ffffb62c4120caa8 EFLAGS: 00010287 RAX: 0000000000000003 RBX: ffffb62c4120cb14 RCX: 0000000000000ec0 RDX: 0000000000001000 RSI: ffffa06e5d7dc000 RDI: 0000000000000003 RBP: ffffa06e5d7ddec0 R08: ffffa06e6120a800 R09: ffffa06e7a119900 R10: 0000000000002310 R11: ffffa06e5d7dcec0 R12: ffffe4360575f740 R13: ffffe43600000000 R14: 0000000000000002 R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffffa0755f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f147b76b0f8 CR3: 00000001615d4000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: ? __warn+0x84/0x130 ? skb_try_coalesce+0x504/0x590 ? report_bug+0x18a/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? skb_try_coalesce+0x504/0x590 inet_frag_reasm_finish+0x11f/0x2e0 ip_defrag+0x37a/0x900 ip_local_deliver+0x51/0x120 ip_sublist_rcv_finish+0x64/0x70 ip_sublist_rcv+0x179/0x210 ip_list_rcv+0xf9/0x130How to reproduce:ip link set $interface1 xdp obj xdp_pass.oip link set $interface1 mtu 9000 upip a a 10.0.0.1/24 dev $interface1ip link set $interfac2 mtu 9000 upip a a 10.0.0.2/24 dev $interface2ping 10.0.0.1 -s 65000Following ping.py patch adds xdp-mb-pass case. so ping.py is going to beable to reproduce this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udp: Fix memory accounting leak.Matt Dowling reported a weird UDP memory usage issue.Under normal operation, the UDP memory usage reported in /proc/net/sockstatremains close to zero. However, it occasionally spiked to 524,288 pagesand never dropped. Moreover, the value doubled when the application wasterminated. Finally, it caused intermittent packet drops.We can reproduce the issue with the script below [0]: 1. /proc/net/sockstat reports 0 pages # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 0 2. Run the script till the report reaches 524,288 # python3 test.py & sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT 3. Kill the socket and confirm the number never drops # pkill python3 && sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 524288 4. (necessary since v6.0) Trigger proto_memory_pcpu_drain() # python3 test.py & sleep 1 && pkill python3 5. The number doubles # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 1048577The application set INT_MAX to SO_RCVBUF, which triggered an integeroverflow in udp_rmem_release().When a socket is close()d, udp_destruct_common() purges its receivequeue and sums up skb->truesize in the queue. This total is calculatedand stored in a local unsigned integer variable.The total size is then passed to udp_rmem_release() to adjust memoryaccounting. However, because the function takes a signed integerargument, the total size can wrap around, causing an overflow.Then, the released amount is calculated as follows: 1) Add size to sk->sk_forward_alloc. 2) Round down sk->sk_forward_alloc to the nearest lower multiple of PAGE_SIZE and assign it to amount. 3) Subtract amount from sk->sk_forward_alloc. 4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated().When the issue occurred, the total in udp_destruct_common() was 2147484480(INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().At 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and2) sets -2147479552 to amount. 3) reverts the wraparound, so we don'tsee a warning in inet_sock_destruct(). However, udp_memory_allocatedends up doubling at 4).Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves formemory_allocated"), memory usage no longer doubles immediately aftera socket is close()d because __sk_mem_reduce_allocated() caches theamount in udp_memory_per_cpu_fw_alloc. However, the next time a UDPsocket receives a packet, the subtraction takes effect, causing UDPmemory usage to double.This issue makes further memory allocation fail once the socket'ssk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packetdrops.To prevent this issue, let's use unsigned int for the calculation andcall sk_forward_alloc_add() only once for the small delta.Note that first_packet_length() also potentially has the same problem.[0]:from socket import *SO_RCVBUFFORCE = 33INT_MAX = (2 ** 31) - 1s = socket(AF_INET, SOCK_DGRAM)s.bind(('', 0))s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)c = socket(AF_INET, SOCK_DGRAM)c.connect(s.getsockname())data = b'a' * 100while True: c.send(data)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: gadget: check that event count does not exceed event buffer lengthThe event count is read from register DWC3_GEVNTCOUNT.There is a check for the count being zero, but not for exceeding theevent buffer length.Check that event count does not exceed event buffer length,avoiding an out-of-bounds access when memcpy'ing the event.Crash log:Unable to handle kernel paging request at virtual address ffffffc0129be000pc : __memcpy+0x114/0x180lr : dwc3_check_event_buf+0xec/0x348x3 : 0000000000000030 x2 : 000000000000dfc4x1 : ffffffc0129be000 x0 : ffffff87aad60080Call trace:__memcpy+0x114/0x180dwc3_interrupt+0x24/0x34
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Fix "KASAN: slab-use-after-free Read in ib_register_device" problemCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 strlen+0x93/0xa0 lib/string.c:420 __fortify_strlen include/linux/fortify-string.h:268 [inline] get_kobj_path_length lib/kobject.c:118 [inline] kobject_get_path+0x3f/0x2a0 lib/kobject.c:158 kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545 ib_register_device drivers/infiniband/core/device.c:1472 [inline] ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393 rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552 rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225 nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796 rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmsg+0x16d/0x220 net/socket.c:2652 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fThis problem is similar to the problem that thecommit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name")fixes.The root cause is: the function ib_device_rename() renames the name withlock. But in the function kobject_uevent(), this name is accessed withoutlock protection at the same time.The solution is to add the lock protection when this name is accessed inthe function kobject_uevent().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:espintcp: remove encap socket caching to avoid reference leakThe current scheme for caching the encap socket can lead to referenceleaks when we try to delete the netns.The reference chain is: xfrm_state -> enacp_sk -> netnsSince the encap socket is a userspace socket, it holds a reference onthe netns. If we delete the espintcp state (through flush orindividual delete) before removing the netns, the reference on thesocket is dropped and the netns is correctly deleted. Otherwise, thenetns may not be reachable anymore (if all processes within the nshave terminated), so we cannot delete the xfrm state to drop itsreference on the socket.This patch results in a small (~2% in my tests) performanceregression.A GC-type mechanism could be added for the socket cache, to clearreferences if the state hasn't been used "recently", but it's a lotmore complex than just not caching the socket.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k_htc: Abort software beacon handling if disabledA malicious USB device can send a WMI_SWBA_EVENTID event from anath9k_htc-managed device before beaconing has been enabled. This causesa device-by-zero error in the driver, leading to either a crash or anout of bounds read.Prevent this by aborting the handling in ath9k_htc_swba() if beacons arenot enabled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: marvell/cesa - Handle zero-length skcipher requestsDo not access random memory for zero-length skcipher requests.Just return 0.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Fix transport_{g2h,h2g} TOCTOUvsock_find_cid() and vsock_dev_do_ioctl() may race with module unload.transport_{g2h,h2g} may become NULL after the NULL check.Introduce vsock_transport_local_cid() to protect from a potentialnull-ptr-deref.KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]RIP: 0010:vsock_find_cid+0x47/0x90Call Trace: __vsock_bind+0x4b2/0x720 vsock_bind+0x90/0xe0 __sys_bind+0x14d/0x1e0 __x64_sys_bind+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]RIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0Call Trace: __x64_sys_ioctl+0x12d/0x190 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fix initialization of data for instructions that write to subdeviceSome Comedi subdevice instruction handlers are known to accessinstruction data elements beyond the first `insn->n` elements in somecases. The `do_insn_ioctl()` and `do_insnlist_ioctl()` functionsallocate at least `MIN_SAMPLES` (16) data elements to deal with this,but they do not initialize all of that. For Comedi instruction codesthat write to the subdevice, the first `insn->n` data elements arecopied from user-space, but the remaining elements are leftuninitialized. That could be a problem if the subdevice instructionhandler reads the uninitialized data. Ensure that the first`MIN_SAMPLES` elements are initialized before calling these instructionhandlers, filling the uncopied elements with 0. For`do_insnlist_ioctl()`, the same data buffer elements are used forhandling a list of instructions, so ensure the first `MIN_SAMPLES`elements are initialized for each instruction that writes to thesubdevice.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fix use of uninitialized data in insn_rw_emulate_bits()For Comedi `INSN_READ` and `INSN_WRITE` instructions on "digital"subdevices (subdevice types `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO`, and`COMEDI_SUBD_DIO`), it is common for the subdevice driver not to have`insn_read` and `insn_write` handler functions, but to have an`insn_bits` handler function for handling Comedi `INSN_BITS`instructions. In that case, the subdevice's `insn_read` and/or`insn_write` function handler pointers are set to point to the`insn_rw_emulate_bits()` function by `__comedi_device_postconfig()`.For `INSN_WRITE`, `insn_rw_emulate_bits()` currently assumes that thesupplied `data[0]` value is a valid copy from user memory. It will atleast exist because `do_insnlist_ioctl()` and `do_insn_ioctl()` in"comedi_fops.c" ensure at lease `MIN_SAMPLES` (16) elements areallocated. However, if `insn->n` is 0 (which is allowable for`INSN_READ` and `INSN_WRITE` instructions, then `data[0]` may containuninitialized data, and certainly contains invalid data, possibly from adifferent instruction in the array of instructions handled by`do_insnlist_ioctl()`. This will result in an incorrect value beingwritten to the digital output channel (or to the digital input/outputchannel if configured as an output), and may be reflected in theinternal saved state of the channel.Fix it by returning 0 early if `insn->n` is 0, before reaching the codethat accesses `data[0]`. Previously, the function always returned 1 onsuccess, but it is supposed to be the number of data samples actuallyread or written up to `insn->n`, which is 0 in this case.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: das6402: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: /* IRQs 2,3,5,6,7, 10,11,15 are valid for "enhanced" mode */ if ((1 << it->options[1]) & 0x8cec) {However, `it->options[i]` is an unchecked `int` value from userspace, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test. Valid `it->options[1]` values that select the IRQwill be in the range [1,15]. The value 0 explicitly disables the use ofinterrupts.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: das16m1: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: /* only irqs 2, 3, 4, 5, 6, 7, 10, 11, 12, 14, and 15 are valid */ if ((1 << it->options[1]) & 0xdcfc) {However, `it->options[i]` is an unchecked `int` value from userspace, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free in cifs_oplock_breakA race condition can occur in cifs_oplock_break() leading to ause-after-free of the cinode structure when unmounting: cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [last ref, start releasing sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [later] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAFThe issue occurs when umount has already released its reference to thesuperblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), thisreleases the last reference, triggering the immediate cleanup of allinodes under RCU. However, cifs_oplock_break() continues to access thecinode after this point, resulting in use-after-free.Fix this by holding an extra reference to the superblock during theentire oplock break operation. This ensures that the superblock andits inodes remain valid until the oplock break completes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Add down_write(trace_event_sem) when adding trace eventWhen a module is loaded, it adds trace events defined by the module. Itmay also need to modify the modules trace printk formats to replace enumnames with their values.If two modules are loaded at the same time, the adding of the event to theftrace_events list can corrupt the walking of the list in the code that ismodifying the printk format strings and crash the kernel.The addition of the event should take the trace_event_sem for write whileit adds the new event.Also add a lockdep_assert_held() on that semaphore in__trace_add_event_dirs() as it iterates the list.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: exynos: Fix programming of HCI_UTRL_NEXUS_TYPEOn Google gs101, the number of UTP transfer request slots (nutrs) is 32,and in this case the driver ends up programming the UTRL_NEXUS_TYPEincorrectly as 0.This is because the left hand side of the shift is 1, which is of typeint, i.e. 31 bits wide. Shifting by more than that width results inundefined behaviour.Fix this by switching to the BIT() macro, which applies correct typecasting as required. This ensures the correct value is written toUTRL_NEXUS_TYPE (0xffffffff on gs101), and it also fixes a UBSAN shiftwarning: UBSAN: shift-out-of-bounds in drivers/ufs/host/ufs-exynos.c:1113:21 shift exponent 32 is too large for 32-bit type 'int'For consistency, apply the same change to the nutmrs / UTMRL_NEXUS_TYPEwrite.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: initialize more fields in sctp_v6_from_sk()syzbot found that sin6_scope_id was not properly initialized,leading to undefined behavior.Clear sin6_scope_id and sin6_flowinfo.BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983 sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390 sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452 sctp_get_port net/sctp/socket.c:8523 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930 x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fLocal variable addr.i.i created at: sctp_get_port net/sctp/socket.c:8515 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix race condition validating r_parent before applying stateAdd validation to ensure the cached parent directory inode matches thedirectory info in MDS replies. This prevents client-side race conditionswhere concurrent operations (e.g. rename) cause r_parent to become stalebetween request initiation and reply processing, which could lead toapplying state changes to incorrect directory inodes.[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated: When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Disallow concurrent writes in af_alg_sendmsgIssuing two writes to the same af_alg socket is bogus as thedata will be interleaved in an unpredictable fashion. Furthermore,concurrent writes may create inconsistencies in the internalsocket state.Disallow this by adding a new ctx->write field that indiciatesexclusive ownership for writing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mscc: ocelot: Fix use-after-free caused by cyclic delayed workThe origin code calls cancel_delayed_work() in ocelot_stats_deinit()to cancel the cyclic delayed work item ocelot->stats_work. However,cancel_delayed_work() may fail to cancel the work item if it is alreadyexecuting. While destroy_workqueue() does wait for all pending work itemsin the work queue to complete before destroying the work queue, it cannotprevent the delayed work item from being rescheduled within theocelot_check_stats_work() function. This limitation exists because thedelayed work item is only enqueued into the work queue after its timerexpires. Before the timer expiration, destroy_workqueue() has no visibilityof this pending work item. Once the work queue appears empty,destroy_workqueue() proceeds with destruction. When the timer eventuallyexpires, the delayed work item gets queued again, leading to the followingwarning:workqueue: cannot queue ocelot_check_stats_work on wq ocelot-switch-statsWARNING: CPU: 2 PID: 0 at kernel/workqueue.c:2255 __queue_work+0x875/0xaf0...RIP: 0010:__queue_work+0x875/0xaf0...RSP: 0018:ffff88806d108b10 EFLAGS: 00010086RAX: 0000000000000000 RBX: 0000000000000101 RCX: 0000000000000027RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffff88806d123e88RBP: ffffffff813c3170 R08: 0000000000000000 R09: ffffed100da247d2R10: ffffed100da247d1 R11: ffff88806d123e8b R12: ffff88800c00f000R13: ffff88800d7285c0 R14: ffff88806d0a5580 R15: ffff88800d7285a0FS: 0000000000000000(0000) GS:ffff8880e5725000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe18e45ea10 CR3: 0000000005e6c000 CR4: 00000000000006f0Call Trace: ? kasan_report+0xc6/0xf0 ? __pfx_delayed_work_timer_fn+0x10/0x10 ? __pfx_delayed_work_timer_fn+0x10/0x10 call_timer_fn+0x25/0x1c0 __run_timer_base.part.0+0x3be/0x8c0 ? __pfx_delayed_work_timer_fn+0x10/0x10 ? rcu_sched_clock_irq+0xb06/0x27d0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? try_to_wake_up+0xb15/0x1960 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 tmigr_handle_remote_up+0x603/0x7e0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? sched_balance_trigger+0x1c0/0x9f0 ? sched_tick+0x221/0x5a0 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? tick_nohz_handler+0x339/0x440 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups.isra.0+0x42/0x150 tmigr_handle_remote+0x1f4/0x2e0 ? __pfx_tmigr_handle_remote+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 ? hrtimer_interrupt+0x322/0x780 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ...The following diagram reveals the cause of the above warning:CPU 0 (remove) | CPU 1 (delayed work callback)mscc_ocelot_remove() | ocelot_deinit() | ocelot_check_stats_work() ocelot_stats_deinit() | cancel_delayed_work()| ... | queue_delayed_work() destroy_workqueue() | (wait a time) | __queue_work() //UAFThe above scenario actually constitutes a UAF vulnerability.The ocelot_stats_deinit() is only invoked when initializationfailure or resource destruction, so we must ensure that anydelayed work items cannot be rescheduled.Replace cancel_delayed_work() with disable_delayed_work_sync()to guarantee proper cancellation of the delayed work item andensure completion of any currently executing work before theworkqueue is deallocated.A deadlock concern was considered: ocelot_stats_deinit() is calledin a process context and is not holding any locks that the delayedwork item might also need. Therefore, the use of the _sync() variantis safe here.This bug was identified through static analysis. To reproduce theissue and validate the fix, I simulated ocelot-swit---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: fix double req put in p9_fd_cancelledSyzkaller reports a KASAN issue as below:general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f]CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:__list_del include/linux/list.h:114 [inline]RIP: 0010:__list_del_entry include/linux/list.h:137 [inline]RIP: 0010:list_del include/linux/list.h:148 [inline]RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734Call Trace: p9_client_flush+0x351/0x440 net/9p/client.c:614 p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734 p9_client_version net/9p/client.c:920 [inline] p9_client_create+0xb51/0x1240 net/9p/client.c:1027 v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408 v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126 legacy_get_tree+0x108/0x220 fs/fs_context.c:632 vfs_get_tree+0x8e/0x300 fs/super.c:1573 do_new_mount fs/namespace.c:3056 [inline] path_mount+0x6a6/0x1e90 fs/namespace.c:3386 do_mount fs/namespace.c:3399 [inline] __do_sys_mount fs/namespace.c:3607 [inline] __se_sys_mount fs/namespace.c:3584 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3584 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8This happens because of a race condition between:- The 9p client sending an invalid flush request and later cleaning it up;- The 9p client in p9_read_work() canceled all pending requests. Thread 1 Thread 2 ... p9_client_create() ... p9_fd_create() ... p9_conn_create() ... // start Thread 2 INIT_WORK(&m->rq, p9_read_work); p9_read_work() ... p9_client_rpc() ... ... p9_conn_cancel() ... spin_lock(&m->req_lock); ... p9_fd_cancelled() ... ... spin_unlock(&m->req_lock); // status rewrite p9_client_cb(m->client, req, REQ_STATUS_ERROR) // first remove list_del(&req->req_list); ... spin_lock(&m->req_lock) ... // second remove list_del(&req->req_list); spin_unlock(&m->req_lock) ...Commit 74d6a5d56629 ("9p/trans_fd: Fix concurrency del of req_list inp9_fd_cancelled/p9_read_work") fixes a concurrency issue in the 9p filesystemclient where the req_list could be deleted simultaneously by bothp9_read_work and p9_fd_cancelled functions, but for the case where req->statusequals REQ_STATUS_RCVD.Update the check for req->status in p9_fd_cancelled to skip processing notjust received requests, but anything that is not SENT, as whateverchanged the state from SENT also removed the request from its list.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.[updated the check from status == RECV || status == ERROR to status != SENT]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp()The hfsplus_strcasecmp() logic can trigger the issue:[ 117.317703][ T9855] ==================================================================[ 117.318353][ T9855] BUG: KASAN: slab-out-of-bounds in hfsplus_strcasecmp+0x1bc/0x490[ 117.318991][ T9855] Read of size 2 at addr ffff88802160f40c by task repro/9855[ 117.319577][ T9855][ 117.319773][ T9855] CPU: 0 UID: 0 PID: 9855 Comm: repro Not tainted 6.17.0-rc6 #33 PREEMPT(full)[ 117.319780][ T9855] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 117.319783][ T9855] Call Trace:[ 117.319785][ T9855] [ 117.319788][ T9855] dump_stack_lvl+0x1c1/0x2a0[ 117.319795][ T9855] ? __virt_addr_valid+0x1c8/0x5c0[ 117.319803][ T9855] ? __pfx_dump_stack_lvl+0x10/0x10[ 117.319808][ T9855] ? rcu_is_watching+0x15/0xb0[ 117.319816][ T9855] ? lock_release+0x4b/0x3e0[ 117.319821][ T9855] ? __kasan_check_byte+0x12/0x40[ 117.319828][ T9855] ? __virt_addr_valid+0x1c8/0x5c0[ 117.319835][ T9855] ? __virt_addr_valid+0x4a5/0x5c0[ 117.319842][ T9855] print_report+0x17e/0x7e0[ 117.319848][ T9855] ? __virt_addr_valid+0x1c8/0x5c0[ 117.319855][ T9855] ? __virt_addr_valid+0x4a5/0x5c0[ 117.319862][ T9855] ? __phys_addr+0xd3/0x180[ 117.319869][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490[ 117.319876][ T9855] kasan_report+0x147/0x180[ 117.319882][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490[ 117.319891][ T9855] hfsplus_strcasecmp+0x1bc/0x490[ 117.319900][ T9855] ? __pfx_hfsplus_cat_case_cmp_key+0x10/0x10[ 117.319906][ T9855] hfs_find_rec_by_key+0xa9/0x1e0[ 117.319913][ T9855] __hfsplus_brec_find+0x18e/0x470[ 117.319920][ T9855] ? __pfx_hfsplus_bnode_find+0x10/0x10[ 117.319926][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10[ 117.319933][ T9855] ? __pfx___hfsplus_brec_find+0x10/0x10[ 117.319942][ T9855] hfsplus_brec_find+0x28f/0x510[ 117.319949][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10[ 117.319956][ T9855] ? __pfx_hfsplus_brec_find+0x10/0x10[ 117.319963][ T9855] ? __kmalloc_noprof+0x2a9/0x510[ 117.319969][ T9855] ? hfsplus_find_init+0x8c/0x1d0[ 117.319976][ T9855] hfsplus_brec_read+0x2b/0x120[ 117.319983][ T9855] hfsplus_lookup+0x2aa/0x890[ 117.319990][ T9855] ? __pfx_hfsplus_lookup+0x10/0x10[ 117.320003][ T9855] ? d_alloc_parallel+0x2f0/0x15e0[ 117.320008][ T9855] ? __lock_acquire+0xaec/0xd80[ 117.320013][ T9855] ? __pfx_d_alloc_parallel+0x10/0x10[ 117.320019][ T9855] ? __raw_spin_lock_init+0x45/0x100[ 117.320026][ T9855] ? __init_waitqueue_head+0xa9/0x150[ 117.320034][ T9855] __lookup_slow+0x297/0x3d0[ 117.320039][ T9855] ? __pfx___lookup_slow+0x10/0x10[ 117.320045][ T9855] ? down_read+0x1ad/0x2e0[ 117.320055][ T9855] lookup_slow+0x53/0x70[ 117.320065][ T9855] walk_component+0x2f0/0x430[ 117.320073][ T9855] path_lookupat+0x169/0x440[ 117.320081][ T9855] filename_lookup+0x212/0x590[ 117.320089][ T9855] ? __pfx_filename_lookup+0x10/0x10[ 117.320098][ T9855] ? strncpy_from_user+0x150/0x290[ 117.320105][ T9855] ? getname_flags+0x1e5/0x540[ 117.320112][ T9855] user_path_at+0x3a/0x60[ 117.320117][ T9855] __x64_sys_umount+0xee/0x160[ 117.320123][ T9855] ? __pfx___x64_sys_umount+0x10/0x10[ 117.320129][ T9855] ? do_syscall_64+0xb7/0x3a0[ 117.320135][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 117.320141][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 117.320145][ T9855] do_syscall_64+0xf3/0x3a0[ 117.320150][ T9855] ? exc_page_fault+0x9f/0xf0[ 117.320154][ T9855] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 117.320158][ T9855] RIP: 0033:0x7f7dd7908b07[ 117.320163][ T9855] Code: 23 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 08[ 117.320167][ T9855] RSP: 002b:00007ffd5ebd9698 EFLAGS: 00000202 ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-fc: move lsop put work to nvmet_fc_ls_req_opIt's possible for more than one async command to be in flight from__nvmet_fc_send_ls_req. For each command, a tgtport reference is taken.In the current code, only one put work item is queued at a time, whichresults in a leaked reference.To fix this, move the work item to the nvmet_fc_ls_req_op struct, whichalready tracks all resources related to the command.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6}Cilium has a BPF egress gateway feature which forces outgoing K8s Podtraffic to pass through dedicated egress gateways which then SNAT thetraffic in order to interact with stable IPs outside the cluster.The traffic is directed to the gateway via vxlan tunnel in collect mdmode. A recent BPF change utilized the bpf_redirect_neigh() helper toforward packets after the arrival and decap on vxlan, which turned outover time that the kmalloc-256 slab usage in kernel was ever-increasing.The issue was that vxlan allocates the metadata_dst object and attachesit through a fake dst entry to the skb. The latter was never releasedthough given bpf_redirect_neigh() was merely setting the new dst entryvia skb_dst_set() without dropping an existing one first.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: bitblit: bound-check glyph index in bit_putcs*bit_putcs_aligned()/unaligned() derived the glyph pointer from thecharacter value masked by 0xff/0x1ff, which may exceed the actual font'sglyph count and read past the end of the built-in font array.Clamp the index to the actual glyph count before computing the address.This fixes a global out-of-bounds read reported by syzbot.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: jq is a command-line JSON processor. In versions up to and including 1.7.1, a heap-buffer-overflow is present in function `jv_string_vfmt` in the jq_fuzz_execute harness from oss-fuzz. This crash happens on file jv.c, line 1456 `void* p = malloc(sz);`. As of time of publication, no patched versions are available.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.1).
-
Description: xz is a pure golang package for reading and writing xz-compressed files. Prior to version 0.5.14, it is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn't include a magic number or has a checksum to detect such an issue according to the specification. Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done. This issue has been patched in version 0.5.14.
Packages affected:
- sle-module-public-cloud-release == 15.5 (version in image is 15.5-150500.43.2).
- google-osconfig-agent > 0-0 (version in image is 20250416.02-150000.1.50.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 == 15.5 (version in image is 15.5-150500.43.2).
- google-guest-agent > 0-0 (version in image is 20250506.01-150000.1.63.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:e1000: fix OOB in e1000_tbi_should_accept()In e1000_tbi_should_accept() we read the last byte of the frame via'data[length - 1]' to evaluate the TBI workaround. If the descriptor-reported length is zero or larger than the actual RX buffer size, thisread goes out of bounds and can hit unrelated slab objects. The issueis observed from the NAPI receive path (e1000_clean_rx_irq):==================================================================BUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790Read of size 1 at addr ffff888014114e54 by task sshd/363CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x5a/0x74 print_address_description+0x7b/0x440 print_report+0x101/0x200 kasan_report+0xc1/0xf0 e1000_tbi_should_accept+0x610/0x790 e1000_clean_rx_irq+0xa8c/0x1110 e1000_clean+0xde2/0x3c10 __napi_poll+0x98/0x380 net_rx_action+0x491/0xa20 __do_softirq+0x2c9/0x61d do_softirq+0xd1/0x120 __local_bh_enable_ip+0xfe/0x130 ip_finish_output2+0x7d5/0xb00 __ip_queue_xmit+0xe24/0x1ab0 __tcp_transmit_skb+0x1bcb/0x3340 tcp_write_xmit+0x175d/0x6bd0 __tcp_push_pending_frames+0x7b/0x280 tcp_sendmsg_locked+0x2e4f/0x32d0 tcp_sendmsg+0x24/0x40 sock_write_iter+0x322/0x430 vfs_write+0x56c/0xa60 ksys_write+0xd1/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f511b476b10Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003 Allocated by task 1: __kasan_krealloc+0x131/0x1c0 krealloc+0x90/0xc0 add_sysfs_param+0xcb/0x8a0 kernel_add_sysfs_param+0x81/0xd4 param_sysfs_builtin+0x138/0x1a6 param_sysfs_init+0x57/0x5b do_one_initcall+0x104/0x250 do_initcall_level+0x102/0x132 do_initcalls+0x46/0x74 kernel_init_freeable+0x28f/0x393 kernel_init+0x14/0x1a0 ret_from_fork+0x22/0x30The buggy address belongs to the object at ffff888014114000 which belongs to the cache kmalloc-2k of size 2048The buggy address is located 1620 bytes to the right of 2048-byte region [ffff888014114000, ffff888014114800]The buggy address belongs to the physical page:page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0flags: 0x100000000010200(slab|head|node=0|zone=1)raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detected==================================================================This happens because the TBI check unconditionally dereferences the lastbyte without validating the reported length first: u8 last_byte = *(data + length - 1);Fix by rejecting the frame early if the length is zero, or if it exceedsadapter->rx_buffer_len. This preserves the TBI workaround semantics forvalid frames and prevents touching memory beyond the RX buffer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: j1939: make j1939_session_activate() fail if device is no longer registeredsyzbot is still reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2even after commit 93a27b5891b8 ("can: j1939: add missing calls inNETDEV_UNREGISTER notification handler") was added. A debug printk() patchfound that j1939_session_activate() can succeed even afterj1939_cancel_active_session() from j1939_netdev_notify(NETDEV_UNREGISTER)has completed.Since j1939_cancel_active_session() is processed with the session list lockheld, checking ndev->reg_state in j1939_session_activate() with the sessionlist lock held can reliably close the race window.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: suspend array while updating raid_disks via sysfsIn raid1_reshape(), freeze_array() is called before modifying the r1biomemory pool (conf->r1bio_pool) and conf->raid_disks, andunfreeze_array() is called after the update is completed.However, freeze_array() only waits until nr_sync_pending and(nr_pending - nr_queued) of all buckets reaches zero. When an I/O erroroccurs, nr_queued is increased and the corresponding r1bio is queued toeither retry_list or bio_end_io_list. As a result, freeze_array() mayunblock before these r1bios are released.This can lead to a situation where conf->raid_disks and the mempool havealready been updated while queued r1bios, allocated with the oldraid_disks value, are later released. Consequently, free_r1bio() mayaccess memory out of bounds in put_all_bios() and release r1bios of thewrong size to the new mempool, potentially causing issues with themempool as well.Since only normal I/O might increase nr_queued while an I/O error occurs,suspending the array avoids this issue.Note: Updating raid_disks via ioctl SET_ARRAY_INFO already suspendsthe array. Therefore, we suspend the array when updating raid_disksvia sysfs to avoid this issue too.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: A security flaw has been discovered in vim up to 9.1.1615. Affected by this vulnerability is the function main of the file src/xxd/xxd.c of the component xxd. The manipulation results in buffer overflow. The attack requires a local approach. The exploit has been released to the public and may be exploited. Upgrading to version 9.1.1616 addresses this issue. The patch is identified as eeef7c77436a78cd27047b0f5fa6925d56de3cb0. It is recommended to upgrade the affected component.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- vim > 0-0 (version in image is 9.2.0280-150500.20.46.1).
-
Description: A flaw was found in the libxml2 library. This uncontrolled resource consumption vulnerability occurs when processing XML catalogs that contain repeated elements pointing to the same downstream catalog. A remote attacker can exploit this by supplying crafted catalogs, causing the parser to redundantly traverse catalog chains. This leads to excessive CPU consumption and degrades application availability, resulting in a denial-of-service condition.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libxml2-2 > 0-0 (version in image is 2.10.3-150500.5.38.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix memory leak in skb_segment_list for GRO packetsWhen skb_segment_list() is called during packet forwarding, it handlespackets that were aggregated by the GRO engine.Historically, the segmentation logic in skb_segment_list assumes thatindividual segments are split from a parent SKB and may need to carrytheir own socket memory accounting. Accordingly, the code transferstruesize from the parent to the newly created segments.Prior to commit ed4cccef64c1 ("gro: fix ownership transfer"), thistruesize subtraction in skb_segment_list() was valid because fragmentsstill carry a reference to the original socket.However, commit ed4cccef64c1 ("gro: fix ownership transfer") changedthis behavior by ensuring that fraglist entries are explicitlyorphaned (skb->sk = NULL) to prevent illegal orphaning later in thestack. This change meant that the entire socket memory charge remainedwith the head SKB, but the corresponding accounting logic inskb_segment_list() was never updated.As a result, the current code unconditionally adds each fragment'struesize to delta_truesize and subtracts it from the parent SKB. Sincethe fragments are no longer charged to the socket, this subtractionresults in an effective under-count of memory when the head is freed.This causes sk_wmem_alloc to remain non-zero, preventing socketdestruction and leading to a persistent memory leak.The leak can be observed via KMEMLEAK when tearing down the networkingenvironment:unreferenced object 0xffff8881e6eb9100 (size 2048): comm "ping", pid 6720, jiffies 4295492526 backtrace: kmem_cache_alloc_noprof+0x5c6/0x800 sk_prot_alloc+0x5b/0x220 sk_alloc+0x35/0xa00 inet6_create.part.0+0x303/0x10d0 __sock_create+0x248/0x640 __sys_socket+0x11b/0x1d0Since skb_segment_list() is exclusively used for SKB_GSO_FRAGLISTpackets constructed by GRO, the truesize adjustment is removed.The call to skb_release_head_state() must be preserved. As documented incommit cf673ed0e057 ("net: fix fraglist segmentation reference countleak"), it is still required to correctly drop references to SKBextensions that may be overwritten during __copy_skb_header().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc: fix use-after-free in driver_override_show()The driver_override_show() function reads the driver_override stringwithout holding the device_lock. However, driver_override_store() usesdriver_set_override(), which modifies and frees the string while holdingthe device_lock.This can result in a concurrent use-after-free if the string is freedby the store function while being read by the show function.Fix this by holding the device_lock around the read operation.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: zlib before 1.3.2 allows CPU consumption via crc32_combine64 and crc32_combine_gen64 because x2nmodp can do right shifts within a loop that has no termination condition.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libz1 > 0-0 (version in image is 1.2.13-150500.4.6.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: 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]Also note that we do not enable the driver_override feature of structbus_type, as SPI - in contrast to most other buses - passes "" tosysfs_emit() when the driver_override pointer is NULL. Thus, printing"\n" instead of "(null)\n".
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: jq is a command-line JSON processor. Commits before 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b contain a vulnerability where CLI input parsing allows validation bypass via embedded NUL bytes. When reading JSON from files or stdin, jq uses strlen() to determine buffer length instead of the actual byte count from fgets(), causing it to truncate input at the first NUL byte and parse only the preceding prefix. This enables an attacker to craft input with a benign JSON prefix before a NUL byte followed by malicious trailing data, where jq validates only the prefix as valid JSON while silently discarding the suffix. Workflows relying on jq to validate untrusted JSON before forwarding it to downstream consumers are susceptible to parser differential attacks, as those consumers may process the full input including the malicious trailing bytes. This issue has been patched by commit 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libssh-config > 0-0 (version in image is 0.9.8-150400.3.17.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix zero size inode with non-zero size after log replayWhen logging that an inode exists, as part of logging a new name orlogging new dir entries for a directory, we always set the generation ofthe logged inode item to 0. This is to signal during log replay (inoverwrite_item()), that we should not set the i_size since we only loggedthat an inode exists, so the i_size of the inode in the subvolume treemust be preserved (as when we log new names or that an inode exists, wedon't log extents).This works fine except when we have already logged an inode in full modeor it's the first time we are logging an inode created in a pasttransaction, that inode has a new i_size of 0 and then we log a new namefor the inode (due to a new hardlink or a rename), in which case we logan i_size of 0 for the inode and a generation of 0, which causes the logreplay code to not update the inode's i_size to 0 (in overwrite_item()).An example scenario: mkdir /mnt/dir xfs_io -f -c "pwrite 0 64K" /mnt/dir/foo sync xfs_io -c "truncate 0" -c "fsync" /mnt/dir/foo ln /mnt/dir/foo /mnt/dir/bar xfs_io -c "fsync" /mnt/dir
After log replay the file remains with a size of 64K. This is because whenwe first log the inode, when we fsync file foo, we log its current i_sizeof 0, and then when we create a hard link we log again the inode in existsmode (LOG_INODE_EXISTS) but we set a generation of 0 for the inode item weadd to the log tree, so during log replay overwrite_item() sees that thegeneration is 0 and i_size is 0 so we skip updating the inode's i_sizefrom 64K to 0.Fix this by making sure at fill_inode_item() we always log the realgeneration of the inode if it was logged in the current transaction withthe i_size we logged before. Also if an inode created in a previoustransaction is logged in exists mode only, make sure we log the i_sizestored in the inode item located from the commit root, so that if we logmultiple times that the inode exists we get the correct i_size.A test case for fstests will follow soon.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- glibc > 0-0 (version in image is 2.31-150300.98.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- glibc > 0-0 (version in image is 2.31-150300.98.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: fix incomplete validation of ioctl argWe tested and found an alarm caused by nbd_ioctl arg without verification.The UBSAN warning calltrace like below:UBSAN: Undefined behaviour in fs/buffer.c:1709:35signed integer overflow:-9223372036854775808 - 1 cannot be represented in type 'long long int'CPU: 3 PID: 2523 Comm: syz-executor.0 Not tainted 4.19.90 #1Hardware name: linux,dummy-virt (DT)Call trace: dump_backtrace+0x0/0x3f0 arch/arm64/kernel/time.c:78 show_stack+0x28/0x38 arch/arm64/kernel/traps.c:158 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x170/0x1dc lib/dump_stack.c:118 ubsan_epilogue+0x18/0xb4 lib/ubsan.c:161 handle_overflow+0x188/0x1dc lib/ubsan.c:192 __ubsan_handle_sub_overflow+0x34/0x44 lib/ubsan.c:206 __block_write_full_page+0x94c/0xa20 fs/buffer.c:1709 block_write_full_page+0x1f0/0x280 fs/buffer.c:2934 blkdev_writepage+0x34/0x40 fs/block_dev.c:607 __writepage+0x68/0xe8 mm/page-writeback.c:2305 write_cache_pages+0x44c/0xc70 mm/page-writeback.c:2240 generic_writepages+0xdc/0x148 mm/page-writeback.c:2329 blkdev_writepages+0x2c/0x38 fs/block_dev.c:2114 do_writepages+0xd4/0x250 mm/page-writeback.c:2344The reason for triggering this warning is __block_write_full_page()-> i_size_read(inode) - 1 overflow.inode->i_size is assigned in __nbd_ioctl() -> nbd_set_size() -> bytesize.We think it is necessary to limit the size of arg to prevent errors.Moreover, __nbd_ioctl() -> nbd_add_socket(), arg will be cast to int.Assuming the value of arg is 0x80000000000000001) (on a 64-bit machine),it will become 1 after the coercion, which will return unexpected results.Fix it by adding checks to prevent passing in too large numbers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs/proc: fix uaf in proc_readdir_de()Pde is erased from subdir rbtree through rb_erase(), but not set the nodeto EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()set the erased node to EMPTY, then pde_subdir_next() will return NULL toavoid uaf access.We found an uaf issue while using stress-ng testing, need to run testcasegetdent and tun in the same time. The steps of the issue is as follows:1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3;2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab;3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access.CPU 0 | CPU 1-------------------------------------------------------------------------traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF |rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: VMX: Fix crash due to uninitialized current_vmcsKVM enables 'Enlightened VMCS' and 'Enlightened MSR Bitmap' when running asa nested hypervisor on top of Hyper-V. When MSR bitmap is updated,evmcs_touch_msr_bitmap function uses current_vmcs per-cpu variable to markthat the msr bitmap was changed.vmx_vcpu_create() modifies the msr bitmap via vmx_disable_intercept_for_msr-> vmx_msr_bitmap_l01_changed which in the end calls this function. Thefunction checks for current_vmcs if it is null but the check isinsufficient because current_vmcs is not initialized. Because of this, thecode might incorrectly write to the structure pointed by current_vmcs valueleft by another task. Preemption is not disabled, the current task can bepreempted and moved to another CPU while current_vmcs is accessed multipletimes from evmcs_touch_msr_bitmap() which leads to crash.The manipulation of MSR bitmaps by callers happens only for vmcs01 so thesolution is to use vmx->vmcs01.vmcs instead of current_vmcs. BUG: kernel NULL pointer dereference, address: 0000000000000338 PGD 4e1775067 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI ... RIP: 0010:vmx_msr_bitmap_l01_changed+0x39/0x50 [kvm_intel] ... Call Trace: vmx_disable_intercept_for_msr+0x36/0x260 [kvm_intel] vmx_vcpu_create+0xe6/0x540 [kvm_intel] kvm_arch_vcpu_create+0x1d1/0x2e0 [kvm] kvm_vm_ioctl_create_vcpu+0x178/0x430 [kvm] kvm_vm_ioctl+0x53f/0x790 [kvm] __x64_sys_ioctl+0x8a/0xc0 do_syscall_64+0x5c/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: netem: account for backlog updates from child qdiscIn general, 'qlen' of any classful qdisc should keep track of thenumber of packets that the qdisc itself and all of its children holds.In case of netem, 'qlen' only accounts for the packets in its internaltfifo. When netem is used with a child qdisc, the child qdisc can use'qdisc_tree_reduce_backlog' to inform its parent, netem, about createdor dropped SKBs. This function updates 'qlen' and the backlog statisticsof netem, but netem does not account for changes made by a child qdisc.'qlen' then indicates the wrong number of packets in the tfifo.If a child qdisc creates new SKBs during enqueue and informs its parentabout this, netem's 'qlen' value is increased. When netem dequeues thenewly created SKBs from the child, the 'qlen' in netem is not updated.If 'qlen' reaches the configured sch->limit, the enqueue function stopsworking, even though the tfifo is not full.Reproduce the bug:Ensure that the sender machine has GSO enabled. Configure netem as rootqdisc and tbf as its child on the outgoing interface of the machineas follows:$ tc qdisc add dev root handle 1: netem delay 100ms limit 100$ tc qdisc add dev parent 1:0 tbf rate 50Mbit burst 1542 latency 50msSend bulk TCP traffic out via this interface, e.g., by running an iPerf3client on the machine. Check the qdisc statistics:$ tc -s qdisc show dev Statistics after 10s of iPerf3 TCP test before the fix (note thatnetem's backlog > limit, netem stopped accepting packets):qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0) backlog 4294528236b 1155p requeues 0qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0) backlog 0b 0p requeues 0Statistics after the fix:qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0) backlog 0b 0p requeues 0qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0) backlog 0b 0p requeues 0tbf segments the GSO SKBs (tbf_segment) and updates the netem's 'qlen'.The interface fully stops transferring packets and "locks". In this case,the child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is atits limit and no more packets are accepted.This patch adds a counter for the entries in the tfifo. Netem's 'qlen' isonly decreased when a packet is returned by its dequeue function, and notduring enqueuing into the child qdisc. External updates to 'qlen' are thusaccounted for and only the behavior of the backlog statistics changes. Asin other qdiscs, 'qlen' then keeps track of how many packets are held innetem and all of its children. As before, sch->limit remains as themaximum number of packets in the tfifo. The same applies to netem'sbacklog statistics.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry()There are actually 2 problems:- deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds.- The memmove itself should move size - i - 1 elements, because the last element is out of bounds.The out-of-bounds element still remains out of bounds after beingaccessed, so the problem is only that we touch it, not that it becomesin active use. But I suppose it can lead to issues if the out-of-boundselement is part of an unmapped page.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bfa: Double-free fixWhen the bfad_im_probe() function fails during initialization, the memorypointed to by bfad->im is freed without setting bfad->im to NULL.Subsequently, during driver uninstallation, when the state machine entersthe bfad_sm_stopping state and calls the bfad_im_probe_undo() function,it attempts to free the memory pointed to by bfad->im again, therebytriggering a double-free vulnerability.Set bfad->im to NULL if probing fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: core: config: Prevent OOB read in SS endpoint companion parsingusb_parse_ss_endpoint_companion() checks descriptor type before length,enabling a potentially odd read outside of the buffer size.Fix this up by checking the size first before looking at any of thefields in the descriptor.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: remove read access to debugfs filesThe 'command' and 'netdev_ops' debugfs files are a legacy debugginginterface supported by the i40e driver since its early days by commit02e9c290814c ("i40e: debugfs interface").Both of these debugfs files provide a read handler which is mostly useless,and which is implemented with questionable logic. They both use a static256 byte buffer which is initialized to the empty string. In the case ofthe 'command' file this buffer is literally never used and simply wastesspace. In the case of the 'netdev_ops' file, the last command written issaved here.On read, the files contents are presented as the name of the devicefollowed by a colon and then the contents of their respective staticbuffer. For 'command' this will always be ": ". For 'netdev_ops',this will be ": ". But note the buffer isshared between all devices operated by this module. At best, it is mostlymeaningless information, and at worse it could be accessed simultaneouslyas there doesn't appear to be any locking mechanism.We have also recently received multiple reports for both read functionsabout their use of snprintf and potential overflow that could result inreading arbitrary kernel memory. For the 'command' file, this is definitelyimpossible, since the static buffer is always zero and never written to.For the 'netdev_ops' file, it does appear to be possible, if the usercarefully crafts the command input, it will be copied into the buffer,which could be large enough to cause snprintf to truncate, which thencauses the copy_to_user to read beyond the length of the buffer allocatedby kzalloc.A minimal fix would be to replace snprintf() with scnprintf() which wouldcap the return to the number of bytes written, preventing an overflow. Amore involved fix would be to drop the mostly useless static buffers,saving 512 bytes and modifying the read functions to stop needing those asinput.Instead, lets just completely drop the read access to these files. Theseare debug interfaces exposed as part of debugfs, and I don't believe thatdropping read access will break any script, as the provided output ispretty useless. You can find the netdev name through other more standardinterfaces, and the 'netdev_ops' interface can easily result in garbage ifyou issue simultaneous writes to multiple devices at once.In order to properly remove the i40e_dbg_netdev_ops_buf, we need torefactor its write function to avoid using the static buffer. Instead, usethe same logic as the i40e_dbg_command_write, with an allocated buffer.Update the code to use this instead of the static buffer, and ensure wefree the buffer on exit. This fixes simultaneous writes to 'netdev_ops' onmultiple devices, and allows us to remove the now unused static bufferalong with removing the read access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:w1: therm: Fix off-by-one buffer overflow in alarms_storeThe sysfs buffer passed to alarms_store() is allocated with 'size + 1'bytes and a NUL terminator is appended. However, the 'size' argumentdoes not account for this extra byte. The original code then allocated'size' bytes and used strcpy() to copy 'buf', which always writes onebyte past the allocated buffer since strcpy() copies until the NULterminator at index 'size'.Fix this by parsing the 'buf' parameter directly using simple_strtoll()without allocating any intermediate memory or string copying. Thisremoves the overflow while simplifying the code.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libpng16-16 > 0-0 (version in image is 1.6.34-150000.3.22.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libssh-config > 0-0 (version in image is 0.9.8-150400.3.17.1).
-
Description: Incorrect behavior order for some Intel(R) Core(tm) Ultra Processors may allow an unauthenticated user to potentially enable information disclosure via physical access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: altmodes/displayport: do not index invalid pin_assignmentsA poorly implemented DisplayPort Alt Mode port partner can indicatethat its pin assignment capabilities are greater than the maximumvalue, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_showwill cause a BRK exception due to an out of bounds array access.Prevent for loop in pin_assignment_show from accessinginvalid values in pin_assignments by adding DP_PIN_ASSIGN_MAXvalue in typec_dp.h and using i < DP_PIN_ASSIGN_MAX as a loopcondition.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: A use-after-free vulnerability has been identified in the GNU GRUB (Grand Unified Bootloader). The flaw occurs because the file-closing process incorrectly retains a memory pointer, leaving an invalid reference to a file system structure. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- grub2 > 0-0 (version in image is 2.06-150500.29.65.1).
-
Description: A Use-After-Free vulnerability has been discovered in GRUB's gettext module. This flaw stems from a programming error where the gettext command remains registered in memory after its module is unloaded. An attacker can exploit this condition by invoking the orphaned command, causing the application to access a memory location that is no longer valid. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- grub2 > 0-0 (version in image is 2.06-150500.29.65.1).
-
Description: A vulnerability has been identified in the GRUB2 bootloader's normal command that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the normal command is not properly unregistered when the module is unloaded. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability. Impact on the data integrity and confidentiality is also not discarded.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- grub2 > 0-0 (version in image is 2.06-150500.29.65.1).
-
Description: A vulnerability in the GRUB2 bootloader has been identified in the normal module. This flaw, a memory Use After Free issue, occurs because the normal_exit command is not properly unregistered when its related module is unloaded. An attacker can exploit this condition by invoking the command after the module has been removed, causing the system to improperly access a previously freed memory location. This leads to a system crash or possible impacts in data confidentiality and integrity.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- grub2 > 0-0 (version in image is 2.06-150500.29.65.1).
-
Description: A flaw was found in glib. An integer overflow during temporary file creation leads to an out-of-bounds memory access, allowing an attacker to potentially perform path traversal or access private temporary file content by creating symbolic links. This vulnerability allows a local attacker to manipulate file paths and access unauthorized data. The core issue stems from insufficient validation of file path lengths during temporary file operations.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libglib-2_0-0 > 0-0 (version in image is 2.70.5-150400.3.34.1).
-
Description: A flaw was found in GLib, which is vulnerable to an integer overflow in the g_string_insert_unichar() function. When the position at which to insert the character is large, the position will overflow, leading to a buffer underwrite.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libglib-2_0-0 > 0-0 (version in image is 2.70.5-150400.3.34.1).
-
Description: A vulnerability has been identified in the GRUB (Grand Unified Bootloader) component. This flaw occurs because the bootloader mishandles string conversion when reading information from a USB device, allowing an attacker to exploit inconsistent length values. A local attacker can connect a maliciously configured USB device during the boot sequence to trigger this issue. A successful exploitation may lead GRUB to crash, leading to a Denial of Service. Data corruption may be also possible, although given the complexity of the exploit the impact is most likely limited.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- grub2 > 0-0 (version in image is 2.06-150500.29.65.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.56.1).
-
Description: Unknown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- vim > 0-0 (version in image is 9.2.0280-150500.20.46.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: fix unexpected zeroed page mapping with zram swapTwo processes under CLONE_VM cloning, user process can be corrupted byseeing zeroed page unexpectedly. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage valid data swap_slot_free_notify delete zram entry swap_readpage zeroed(invalid) data pte_lock map the *zero data* to userspace pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return and next refault will read zeroed dataThe swap_slot_free_notify is bogus for CLONE_VM case since it doesn'tincrease the refcount of swap slot at copy_mm so it couldn't catch upwhether it's safe or not to discard data from backing device. In thecase, only the lock it could rely on to synchronize swap slot freeing ispage table lock. Thus, this patch gets rid of the swap_slot_free_notifyfunction. With this patch, CPU A will see correct data. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage original data pte_lock map the original data swap_free swap_range_free bd_disk->fops->swap_slot_free_notify swap_readpage read zeroed data pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return on next refault will see mapped data by CPU BThe concern of the patch would increase memory consumption since itcould keep wasted memory with compressed form in zram as well asuncompressed form in address space. However, most of cases of zram usesno readahead and do_swap_page is followed by swap_free so it will freethe compressed form from in zram quickly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: Restrict usage of GPIO chip irq members before initializationGPIO chip irq members are exposed before they could be completelyinitialized and this leads to race conditions.One such issue was observed for the gc->irq.domain variable whichwas accessed through the I2C interface in gpiochip_to_irq() beforeit could be initialized by gpiochip_add_irqchip(). This resulted inKernel NULL pointer dereference.Following are the logs for reference :-kernel: Call Trace:kernel: gpiod_to_irq+0x53/0x70kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0kernel: i2c_acpi_get_irq+0xc0/0xd0kernel: i2c_device_probe+0x28a/0x2a0kernel: really_probe+0xf2/0x460kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0To avoid such scenarios, restrict usage of GPIO chip irq members beforethey are completely initialized.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip: Fix data-races around sysctl_ip_prot_sock.sysctl_ip_prot_sock is accessed concurrently, and there is always a chanceof data-race. So, all readers and writers need some basic protection toavoid load/store-tearing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igmp: Fix data-races around sysctl_igmp_llm_reports.While reading sysctl_igmp_llm_reports, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.This test can be packed into a helper, so such changes will be in thefollow-up series after net is merged into net-next. if (ipv4_is_local_multicast(pmc->multiaddr) && !READ_ONCE(net->ipv4.sysctl_igmp_llm_reports))
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext2: Add more validity checks for inode countsAdd checks verifying number of inodes stored in the superblock matchesthe number computed from number of inodes per group. Also verify we haveat least one block worth of inodes per group. This prevents crashes oncorrupted filesystems.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix a race condition between login_work and the login threadIn case a malicious initiator sends some random data immediately after alogin PDU; the iscsi_target_sk_data_ready() callback will schedule thelogin_work and, at the same time, the negotiation may end without clearingthe LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges arerequired to complete the login).The login has been completed but the login_work function will find theLOGIN_FLAGS_INITIAL_PDU flag set and will never stop from reschedulingitself; at this point, if the initiator drops the connection, theiscsit_conn structure will be freed, login_work will dereference a releasedsocket structure and the kernel crashes.BUG: kernel NULL pointer dereference, address: 0000000000000230PF: supervisor write access in kernel modePF: error_code(0x0002) - not-present pageWorkqueue: events iscsi_target_do_login_rx [iscsi_target_mod]RIP: 0010:_raw_read_lock_bh+0x15/0x30Call trace: iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod] process_one_work+0x1e8/0x3c0Fix this bug by forcing login_work to stop after the login has beencompleted and the socket callbacks have been restored.Add a comment to clearify the return values of iscsi_target_do_login()
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: call __btrfs_remove_free_space_cache_locked on cache load failureNow that lockdep is staying enabled through our entire CI runs I startedseeing the following stack in generic/475------------[ cut here ]------------WARNING: CPU: 1 PID: 2171864 at fs/btrfs/discard.c:604 btrfs_discard_update_discardable+0x98/0xb0CPU: 1 PID: 2171864 Comm: kworker/u4:0 Not tainted 5.19.0-rc8+ #789Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014Workqueue: btrfs-cache btrfs_work_helperRIP: 0010:btrfs_discard_update_discardable+0x98/0xb0RSP: 0018:ffffb857c2f7bad0 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff8c85c605c200 RCX: 0000000000000001RDX: 0000000000000000 RSI: ffffffff86807c5b RDI: ffffffff868a831eRBP: ffff8c85c4c54000 R08: 0000000000000000 R09: 0000000000000000R10: ffff8c85c66932f0 R11: 0000000000000001 R12: ffff8c85c3899010R13: ffff8c85d5be4f40 R14: ffff8c85c4c54000 R15: ffff8c86114bfa80FS: 0000000000000000(0000) GS:ffff8c863bd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f2e7f168160 CR3: 000000010289a004 CR4: 0000000000370ee0Call Trace: __btrfs_remove_free_space_cache+0x27/0x30 load_free_space_cache+0xad2/0xaf0 caching_thread+0x40b/0x650 ? lock_release+0x137/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_is_held_type+0xe2/0x140 process_one_work+0x271/0x590 ? process_one_work+0x590/0x590 worker_thread+0x52/0x3b0 ? process_one_work+0x590/0x590 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30This is the code ctl = block_group->free_space_ctl; discard_ctl = &block_group->fs_info->discard_ctl; lockdep_assert_held(&ctl->tree_lock);We have a temporary free space ctl for loading the free space cache inorder to avoid having allocations happening while we're loading thecache. When we hit an error we free it all up, however this also callsbtrfs_discard_update_discardable, which requiresblock_group->free_space_ctl->tree_lock to be held. However this is ourtemporary ctl so this lock isn't held. Fix this by calling__btrfs_remove_free_space_cache_locked instead so that we only clean upthe entries and do not mess with the discardable stats.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix NULL dereference on q->elevator in blk_mq_elv_switch_noneAfter grabbing q->sysfs_lock, q->elevator may become NULL because ofelevator switch.Fix the NULL dereference on q->elevator by checking it with lock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: insert tree mod log move in push_node_leftThere is a fairly unlikely race condition in tree mod log rewind thatcan result in a kernel panic which has the following trace: [530.569] BTRFS critical (device sda3): unable to find logical 0 length 4096 [530.585] BTRFS critical (device sda3): unable to find logical 0 length 4096 [530.602] BUG: kernel NULL pointer dereference, address: 0000000000000002 [530.618] #PF: supervisor read access in kernel mode [530.629] #PF: error_code(0x0000) - not-present page [530.641] PGD 0 P4D 0 [530.647] Oops: 0000 [#1] SMP [530.654] CPU: 30 PID: 398973 Comm: below Kdump: loaded Tainted: G S O K 5.12.0-0_fbk13_clang_7455_gb24de3bdb045 #1 [530.680] Hardware name: Quanta Mono Lake-M.2 SATA 1HY9U9Z001G/Mono Lake-M.2 SATA, BIOS F20_3A15 08/16/2017 [530.703] RIP: 0010:__btrfs_map_block+0xaa/0xd00 [530.755] RSP: 0018:ffffc9002c2f7600 EFLAGS: 00010246 [530.767] RAX: ffffffffffffffea RBX: ffff888292e41000 RCX: f2702d8b8be15100 [530.784] RDX: ffff88885fda6fb8 RSI: ffff88885fd973c8 RDI: ffff88885fd973c8 [530.800] RBP: ffff888292e410d0 R08: ffffffff82fd7fd0 R09: 00000000fffeffff [530.816] R10: ffffffff82e57fd0 R11: ffffffff82e57d70 R12: 0000000000000000 [530.832] R13: 0000000000001000 R14: 0000000000001000 R15: ffffc9002c2f76f0 [530.848] FS: 00007f38d64af000(0000) GS:ffff88885fd80000(0000) knlGS:0000000000000000 [530.866] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [530.880] CR2: 0000000000000002 CR3: 00000002b6770004 CR4: 00000000003706e0 [530.896] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [530.912] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [530.928] Call Trace: [530.934] ? btrfs_printk+0x13b/0x18c [530.943] ? btrfs_bio_counter_inc_blocked+0x3d/0x130 [530.955] btrfs_map_bio+0x75/0x330 [530.963] ? kmem_cache_alloc+0x12a/0x2d0 [530.973] ? btrfs_submit_metadata_bio+0x63/0x100 [530.984] btrfs_submit_metadata_bio+0xa4/0x100 [530.995] submit_extent_page+0x30f/0x360 [531.004] read_extent_buffer_pages+0x49e/0x6d0 [531.015] ? submit_extent_page+0x360/0x360 [531.025] btree_read_extent_buffer_pages+0x5f/0x150 [531.037] read_tree_block+0x37/0x60 [531.046] read_block_for_search+0x18b/0x410 [531.056] btrfs_search_old_slot+0x198/0x2f0 [531.066] resolve_indirect_ref+0xfe/0x6f0 [531.076] ? ulist_alloc+0x31/0x60 [531.084] ? kmem_cache_alloc_trace+0x12e/0x2b0 [531.095] find_parent_nodes+0x720/0x1830 [531.105] ? ulist_alloc+0x10/0x60 [531.113] iterate_extent_inodes+0xea/0x370 [531.123] ? btrfs_previous_extent_item+0x8f/0x110 [531.134] ? btrfs_search_path_in_tree+0x240/0x240 [531.146] iterate_inodes_from_logical+0x98/0xd0 [531.157] ? btrfs_search_path_in_tree+0x240/0x240 [531.168] btrfs_ioctl_logical_to_ino+0xd9/0x180 [531.179] btrfs_ioctl+0xe2/0x2eb0This occurs when logical inode resolution takes a tree mod log sequencenumber, and then while backref walking hits a rewind on a busy nodewhich has the following sequence of tree mod log operations (numbersfilled in from a specific example, but they are somewhat arbitrary) REMOVE_WHILE_FREEING slot 532 REMOVE_WHILE_FREEING slot 531 REMOVE_WHILE_FREEING slot 530 ... REMOVE_WHILE_FREEING slot 0 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... REMOVE slot 0 ADD slot 455 ADD slot 454 ADD slot 453 ... ADD slot 0 MOVE src slot 0 -> dst slot 456 nritems 533 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... REMOVE slot 0When this sequence gets applied via btrfs_tree_mod_log_rewind, itallocates a fresh rewind eb, and first inserts the correct key info forthe 533 elements, then overwrites the first 456 of them, then decrementsthe count by 456 via the add ops, then rewinds the move by doing amemmove from 456:988->0:532. We have never written anything past 532,---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this processThere are two states for ubifs writing pages:1. Dirty, Private2. Not Dirty, Not PrivateThe normal process cannot go to ubifs_releasepage() which means thereexists pages being private but not dirty. Reproducer[1] shows that itcould occur (which maybe related to [2]) with following process: PA PB PClock(page)[PA]ubifs_write_end attach_page_private // set Private __set_page_dirty_nobuffers // set Dirtyunlock(page)write_cache_pages[PA] lock(page) clear_page_dirty_for_io(page) // clear Dirty ubifs_writepage do_truncation[PB] truncate_setsize i_size_write(inode, newsize) // newsize = 0 i_size = i_size_read(inode) // i_size = 0 end_index = i_size >> PAGE_SHIFT if (page->index > end_index) goto out // jumpout:unlock(page) // Private, Not Dirty generic_fadvise[PC] lock(page) invalidate_inode_page try_to_release_page ubifs_releasepage ubifs_assert(c, 0) // bad assertion! unlock(page) truncate_pagecache[PB]Then we may get following assertion failed: UBIFS error (ubi0:0 pid 1683): ubifs_assert_failed [ubifs]: UBIFS assert failed: 0, in fs/ubifs/file.c:1513 UBIFS warning (ubi0:0 pid 1683): ubifs_ro_mode [ubifs]: switched to read-only mode, error -22 CPU: 2 PID: 1683 Comm: aa Not tainted 5.16.0-rc5-00184-g0bca5994cacc-dirty #308 Call Trace: dump_stack+0x13/0x1b ubifs_ro_mode+0x54/0x60 [ubifs] ubifs_assert_failed+0x4b/0x80 [ubifs] ubifs_releasepage+0x67/0x1d0 [ubifs] try_to_release_page+0x57/0xe0 invalidate_inode_page+0xfb/0x130 __invalidate_mapping_pages+0xb9/0x280 invalidate_mapping_pagevec+0x12/0x20 generic_fadvise+0x303/0x3c0 ksys_fadvise64_64+0x4c/0xb0[1] https://bugzilla.kernel.org/show_bug.cgi?id=215373[2] https://linux-mtd.infradead.narkive.com/NQoBeT1u/patch-rfc-ubifs-fix-assert-failed-in-ubifs-set-page-dirty
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix memory leak in WMI firmware statsMemory allocated for firmware pdev, vdev and beacon statisticsare not released during rmmod.Fix it by calling ath11k_fw_stats_free() function before hardwareunregister.While at it, avoid calling ath11k_fw_stats_free() while processingthe firmware stats received in the WMI event because the local listis getting spliced and reinitialised and hence there are no elementsin the list after splicing.Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: fix potential deadlock in netlink_set_err()syzbot reported a possible deadlock in netlink_set_err() [1]A similar issue was fixed in commit 1d482e666b8e ("netlink: disable IRQsfor netlink_lock_table()") in netlink_lock_table()This patch adds IRQ safety to netlink_set_err() and __netlink_diag_dump()which were not covered by cited commit.[1]WARNING: possible irq lock inversion dependency detected6.4.0-rc6-syzkaller-00240-g4e9f0ec38852 #0 Not taintedsyz-executor.2/23011 just changed the state of lock:ffffffff8e1a7a58 (nl_table_lock){.+.?}-{2:2}, at: netlink_set_err+0x2e/0x3a0 net/netlink/af_netlink.c:1612but this lock was taken by another, SOFTIRQ-safe lock in the past: (&local->queue_stop_reason_lock){..-.}-{2:2}and interrupts could create inverse lock ordering between them.other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(nl_table_lock); local_irq_disable(); lock(&local->queue_stop_reason_lock); lock(nl_table_lock); lock(&local->queue_stop_reason_lock); *** DEADLOCK ***
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:interconnect: Fix locking for runpm vs reclaimFor cases where icc_bw_set() can be called in callbaths that coulddeadlock against shrinker/reclaim, such as runpm resume, we need todecouple the icc locking. Introduce a new icc_bw_lock for cases wherewe need to serialize bw aggregation and update to decouple that frompaths that require memory allocation such as node/link creation/destruction.Fixes this lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 6.2.0-rc8-debug+ #554 Not tainted ------------------------------------------------------ ring0/132 is trying to acquire lock: ffffff80871916d0 (&gmu->lock){+.+.}-{3:3}, at: a6xx_pm_resume+0xf0/0x234 but task is already holding lock: ffffffdb5aee57e8 (dma_fence_map){++++}-{0:0}, at: msm_job_run+0x68/0x150 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (dma_fence_map){++++}-{0:0}: __dma_fence_might_wait+0x74/0xc0 dma_resv_lockdep+0x1f4/0x2f4 do_one_initcall+0x104/0x2bc kernel_init_freeable+0x344/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x80/0xa8 slab_pre_alloc_hook.constprop.0+0x40/0x25c __kmem_cache_alloc_node+0x60/0x1cc __kmalloc+0xd8/0x100 topology_parse_cpu_capacity+0x8c/0x178 get_cpu_for_node+0x88/0xc4 parse_cluster+0x1b0/0x28c parse_cluster+0x8c/0x28c init_cpu_topology+0x168/0x188 smp_prepare_cpus+0x24/0xf8 kernel_init_freeable+0x18c/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #2 (fs_reclaim){+.+.}-{0:0}: __fs_reclaim_acquire+0x3c/0x48 fs_reclaim_acquire+0x54/0xa8 slab_pre_alloc_hook.constprop.0+0x40/0x25c __kmem_cache_alloc_node+0x60/0x1cc __kmalloc+0xd8/0x100 kzalloc.constprop.0+0x14/0x20 icc_node_create_nolock+0x4c/0xc4 icc_node_create+0x38/0x58 qcom_icc_rpmh_probe+0x1b8/0x248 platform_probe+0x70/0xc4 really_probe+0x158/0x290 __driver_probe_device+0xc8/0xe0 driver_probe_device+0x44/0x100 __driver_attach+0xf8/0x108 bus_for_each_dev+0x78/0xc4 driver_attach+0x2c/0x38 bus_add_driver+0xd0/0x1d8 driver_register+0xbc/0xf8 __platform_driver_register+0x30/0x3c qnoc_driver_init+0x24/0x30 do_one_initcall+0x104/0x2bc kernel_init_freeable+0x344/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #1 (icc_lock){+.+.}-{3:3}: __mutex_lock+0xcc/0x3c8 mutex_lock_nested+0x30/0x44 icc_set_bw+0x88/0x2b4 _set_opp_bw+0x8c/0xd8 _set_opp+0x19c/0x300 dev_pm_opp_set_opp+0x84/0x94 a6xx_gmu_resume+0x18c/0x804 a6xx_pm_resume+0xf8/0x234 adreno_runtime_resume+0x2c/0x38 pm_generic_runtime_resume+0x30/0x44 __rpm_callback+0x15c/0x174 rpm_callback+0x78/0x7c rpm_resume+0x318/0x524 __pm_runtime_resume+0x78/0xbc adreno_load_gpu+0xc4/0x17c msm_open+0x50/0x120 drm_file_alloc+0x17c/0x228 drm_open_helper+0x74/0x118 drm_open+0xa0/0x144 drm_stub_open+0xd4/0xe4 chrdev_open+0x1b8/0x1e4 do_dentry_open+0x2f8/0x38c vfs_open+0x34/0x40 path_openat+0x64c/0x7b4 do_filp_open+0x54/0xc4 do_sys_openat2+0x9c/0x100 do_sys_open+0x50/0x7c __arm64_sys_openat+0x28/0x34 invoke_syscall+0x8c/0x128 el0_svc_common.constprop.0+0xa0/0x11c do_el0_---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't free qgroup space unless specifiedBoris noticed in his simple quotas testing that he was getting a leakwith Sweet Tea's change to subvol create that stopped doing atransaction commit. This was just a side effect of that change.In the delayed inode code we have an optimization that will free extrareservations if we think we can pack a dir item into an already modifiedleaf. Previously this wouldn't be triggered in the subvolume createcase because we'd commit the transaction, it was still possible butmuch harder to trigger. It could actually be triggered if we did amkdir && subvol create with qgroups enabled.This occurs because in btrfs_insert_delayed_dir_index(), which getscalled when we're adding the dir item, we do the following: btrfs_block_rsv_release(fs_info, trans->block_rsv, bytes, NULL);if we're able to skip reserving space.The problem here is that trans->block_rsv points at the temporary blockrsv for the subvolume create, which has qgroup reservations in the blockrsv.This is a problem because btrfs_block_rsv_release() will do thefollowing: if (block_rsv->qgroup_rsv_reserved >= block_rsv->qgroup_rsv_size) { qgroup_to_release = block_rsv->qgroup_rsv_reserved - block_rsv->qgroup_rsv_size; block_rsv->qgroup_rsv_reserved = block_rsv->qgroup_rsv_size; }The temporary block rsv just has ->qgroup_rsv_reserved set,->qgroup_rsv_size == 0. The optimization inbtrfs_insert_delayed_dir_index() sets ->qgroup_rsv_reserved = 0. Thenlater on when we call btrfs_subvolume_release_metadata() which has btrfs_block_rsv_release(fs_info, rsv, (u64)-1, &qgroup_to_release); btrfs_qgroup_convert_reserved_meta(root, qgroup_to_release);qgroup_to_release is set to 0, and we do not convert the reservedmetadata space.The problem here is that the block rsv code has been unconditionallymessing with ->qgroup_rsv_reserved, because the main place this is usedis delalloc, and any time we call btrfs_block_rsv_release() we do itwith qgroup_to_release set, and thus do the proper accounting.The subvolume code is the only other code that uses the qgroupreservation stuff, but it's intermingled with the above optimization,and thus was getting its reservation freed out from underneath it andthus leaking the reserved space.The solution is to simply not mess with the qgroup reservations if wedon't have qgroup_to_release set. This works with the existing code asanything that messes with the delalloc reservations always haveqgroup_to_release set. This fixes the leak that Boris was observing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: fix blktrace debugfs entries leakageCommit 99d055b4fd4b ("block: remove per-disk debugfs files inblk_unregister_queue") moves blk_trace_shutdown() fromblk_release_queue() to blk_unregister_queue(), this is safe if blktraceis created through sysfs, however, there is a regression in cornercase.blktrace can still be enabled after del_gendisk() through ioctl ifthe disk is opened before del_gendisk(), and if blktrace is not shutdownthrough ioctl before closing the disk, debugfs entries will be leaked.Fix this problem by shutdown blktrace in disk_release(), this is safebecause blk_trace_remove() is reentrant.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix lockdep splat and potential deadlock after failure running delayed itemsWhen running delayed items we are holding a delayed node's mutex and thenwe will attempt to modify a subvolume btree to insert/update/delete thedelayed items. However if have an error during the insertions for example,btrfs_insert_delayed_items() may return with a path that has locked extentbuffers (a leaf at the very least), and then we attempt to release thedelayed node at __btrfs_run_delayed_items(), which requires taking thedelayed node's mutex, causing an ABBA type of deadlock. This was reportedby syzbot and the lockdep splat is the following: WARNING: possible circular locking dependency detected 6.5.0-rc7-syzkaller-00024-g93f5de5f648d #0 Not tainted ------------------------------------------------------ syz-executor.2/13257 is trying to acquire lock: ffff88801835c0c0 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256 but task is already holding lock: ffff88802a5ab8e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_lock+0x3c/0x2a0 fs/btrfs/locking.c:198 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (btrfs-tree-00){++++}-{3:3}: __lock_release kernel/locking/lockdep.c:5475 [inline] lock_release+0x36f/0x9d0 kernel/locking/lockdep.c:5781 up_write+0x79/0x580 kernel/locking/rwsem.c:1625 btrfs_tree_unlock_rw fs/btrfs/locking.h:189 [inline] btrfs_unlock_up_safe+0x179/0x3b0 fs/btrfs/locking.c:239 search_leaf fs/btrfs/ctree.c:1986 [inline] btrfs_search_slot+0x2511/0x2f80 fs/btrfs/ctree.c:2230 btrfs_insert_empty_items+0x9c/0x180 fs/btrfs/ctree.c:4376 btrfs_insert_delayed_item fs/btrfs/delayed-inode.c:746 [inline] btrfs_insert_delayed_items fs/btrfs/delayed-inode.c:824 [inline] __btrfs_commit_inode_delayed_items+0xd24/0x2410 fs/btrfs/delayed-inode.c:1111 __btrfs_run_delayed_items+0x1db/0x430 fs/btrfs/delayed-inode.c:1153 flush_space+0x269/0xe70 fs/btrfs/space-info.c:723 btrfs_async_reclaim_metadata_space+0x106/0x350 fs/btrfs/space-info.c:1078 process_one_work+0x92c/0x12c0 kernel/workqueue.c:2600 worker_thread+0xa63/0x1210 kernel/workqueue.c:2751 kthread+0x2b8/0x350 kernel/kthread.c:389 ret_from_fork+0x2e/0x60 arch/x86/kernel/process.c:145 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 -> #0 (&delayed_node->mutex){+.+.}-{3:3}: check_prev_add kernel/locking/lockdep.c:3142 [inline] check_prevs_add kernel/locking/lockdep.c:3261 [inline] validate_chain kernel/locking/lockdep.c:3876 [inline] __lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144 lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761 __mutex_lock_common+0x1d8/0x2530 kernel/locking/mutex.c:603 __mutex_lock kernel/locking/mutex.c:747 [inline] mutex_lock_nested+0x1b/0x20 kernel/locking/mutex.c:799 __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256 btrfs_release_delayed_node fs/btrfs/delayed-inode.c:281 [inline] __btrfs_run_delayed_items+0x2b5/0x430 fs/btrfs/delayed-inode.c:1156 btrfs_commit_transaction+0x859/0x2ff0 fs/btrfs/transaction.c:2276 btrfs_sync_file+0xf56/0x1330 fs/btrfs/file.c:1988 vfs_fsync_range fs/sync.c:188 [inline] vfs_fsync fs/sync.c:202 [inline] do_fsync fs/sync.c:212 [inline] __do_sys_fsync fs/sync.c:220 [inline] __se_sys_fsync fs/sync.c:218 [inline] __x64_sys_fsync+0x196/0x1e0 fs/sync.c:218 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd other info that---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix tags leak when shrink nr_hw_queuesAlthough we don't need to realloc set->tags[] when shrink nr_hw_queues,we need to free them. Or these tags will be leaked.How to reproduce:1. mount -t configfs configfs /mnt2. modprobe null_blk nr_devices=0 submit_queues=83. mkdir /mnt/nullb/nullb04. echo 1 > /mnt/nullb/nullb0/power5. echo 4 > /mnt/nullb/nullb0/submit_queues6. rmdir /mnt/nullb/nullb0In step 4, will alloc 9 tags (8 submit queues and 1 poll queue), thenin step 5, new_nr_hw_queues = 5 (4 submit queues and 1 poll queue).At last in step 6, only these 5 tags are freed, the other 4 tags leaked.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: fix memory leak after finding block group with super blocksAt exclude_super_stripes(), if we happen to find a block group that hassuper blocks mapped to it and we are on a zoned filesystem, we error outas this is not supposed to happen, indicating either a bug or maybe somememory corruption for example. However we are exiting the function withoutfreeing the memory allocated for the logical address of the super blocks.Fix this by freeing the logical address.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp_qoriq: fix memory leak in probe()Smatch complains that:drivers/ptp/ptp_qoriq.c ptp_qoriq_probe()warn: 'base' from ioremap() not released.Fix this by revising the parameter from 'ptp_qoriq->base' to 'base'.This is only a bug if ptp_qoriq_init() returns on thefirst -ENODEV error path.For other error paths ptp_qoriq->base and base are the same.And this change makes the code more readable.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: A vulnerability was found in PAM. The secret information is stored in memory, where the attacker can trigger the victim program to execute by sending characters to its standard input (stdin). As this occurs, the attacker can train the branch predictor to execute an ROP chain speculatively. This flaw could result in leaked passwords, such as those found in /etc/shadow while performing authentications.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- pam > 0-0 (version in image is 1.3.0-150000.6.86.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not BUG_ON() when freeing tree block after errorWhen freeing a tree block, at btrfs_free_tree_block(), if we fail tocreate a delayed reference we don't deal with the error and just do aBUG_ON(). The error most likely to happen is -ENOMEM, and we have acomment mentioning that only -ENOMEM can happen, but that is not true,because in case qgroups are enabled any error returned frombtrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returnedfrom btrfs_search_slot() for example) can be propagated back tobtrfs_free_tree_block().So stop doing a BUG_ON() and return the error to the callers and makethem abort the transaction to prevent leaking space. Syzbot wastriggering this, likely due to memory allocation failure injection.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i3c: mipi-i3c-hci: Mask ring interrupts before ring stop requestBus cleanup path in DMA mode may trigger a RING_OP_STAT interrupt whenthe ring is being stopped. Depending on timing between ring stop requestcompletion, interrupt handler removal and code execution this may leadto a NULL pointer dereference in hci_dma_irq_handler() if it gets to runafter the io_data pointer is set to NULL in hci_dma_cleanup().Prevent this my masking the ring interrupts before ring stop request.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinmux: Use sequential access to access desc->pinmux dataWhen two client of the same gpio call pinctrl_select_state() for thesame functionality, we are seeing NULL pointer issue while accessingdesc->mux_owner.Let's say two processes A, B executing in pin_request() for the same pinand process A updates the desc->mux_usecount but not yet updated thedesc->mux_owner while process B see the desc->mux_usecount which gotupdated by A path and further executes strcmp and while accessingdesc->mux_owner it crashes with NULL pointer.Serialize the access to mux related setting with a mutex lock. cpu0 (process A) cpu1(process B)pinctrl_select_state() { pinctrl_select_state() { pin_request() { pin_request() { ... .... } else { desc->mux_usecount++; desc->mux_usecount && strcmp(desc->mux_owner, owner)) { if (desc->mux_usecount > 1) return 0; desc->mux_owner = owner; } }
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Make sure internal and UAPI bpf_redirect flags don't overlapThe bpf_redirect_info is shared between the SKB and XDP redirect paths,and the two paths use the same numeric flag values in the ri->flagsfield (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means thatif skb bpf_redirect_neigh() is used with a non-NULL params argument and,subsequently, an XDP redirect is performed using the samebpf_redirect_info struct, the XDP path will get confused and end upcrashing, which syzbot managed to trigger.With the stack-allocated bpf_redirect_info, the structure is no longershared between the SKB and XDP paths, so the crash doesn't happenanymore. However, different code paths using identically-numbered flagvalues in the same struct field still seems like a bit of a mess, sothis patch cleans that up by moving the flag definitions together andredefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlapwith the flags used for XDP. It also adds a BUILD_BUG_ON() check to makesure the overlap is not re-introduced by mistake.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64/sve: Discard stale CPU state when handling SVE trapsThe logic for handling SVE traps manipulates saved FPSIMD/SVE stateincorrectly, and a race with preemption can result in a task havingTIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU stateis stale (e.g. with SVE traps enabled). This has been observed to resultin warnings from do_sve_acc() where SVE traps are not expected whileTIF_SVE is set:| if (test_and_set_thread_flag(TIF_SVE))| WARN_ON(1); /* SVE access shouldn't have trapped */Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/The race can occur when the SVE trap handler is preempted before andafter manipulating the saved FPSIMD/SVE state, starting and ending onthe same CPU, e.g.| void do_sve_acc(unsigned long esr, struct pt_regs *regs)| {| // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled| // task->fpsimd_cpu is 0.| // per_cpu_ptr(&fpsimd_last_state, 0) is task.|| ...|| // Preempted; migrated from CPU 0 to CPU 1.| // TIF_FOREIGN_FPSTATE is set.|| get_cpu_fpsimd_context();|| if (test_and_set_thread_flag(TIF_SVE))| WARN_ON(1); /* SVE access shouldn't have trapped */|| sve_init_regs() {| if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {| ...| } else {| fpsimd_to_sve(current);| current->thread.fp_type = FP_STATE_SVE;| }| }|| put_cpu_fpsimd_context();|| // Preempted; migrated from CPU 1 to CPU 0.| // task->fpsimd_cpu is still 0| // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then:| // - Stale HW state is reused (with SVE traps enabled)| // - TIF_FOREIGN_FPSTATE is cleared| // - A return to userspace skips HW state restore| }Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is setby calling fpsimd_flush_task_state() to detach from the saved CPUstate. This ensures that a subsequent context switch will not reuse thestale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing thenew state to be reloaded from memory prior to a return to userspace.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: During unmount, ensure all cached dir instances drop their dentryThe unmount process (cifs_kill_sb() calling close_all_cached_dirs()) canrace with various cached directory operations, which ultimately resultsin dentries not being dropped and these kernel BUGs:BUG: Dentry ffff88814f37e358{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs]VFS: Busy inodes after unmount of cifs (cifs)------------[ cut here ]------------kernel BUG at fs/super.c:661!This happens when a cfid is in the process of being cleaned up when, andhas been removed from the cfids->entries list, including:- Receiving a lease break from the server- Server reconnection triggers invalidate_all_cached_dirs(), which removes all the cfids from the list- The laundromat thread decides to expire an old cfid.To solve these problems, dropping the dentry is done in queued work donein a newly-added cfid_put_wq workqueue, and close_all_cached_dirs()flushes that workqueue after it drops all the dentries of which it'saware. This is a global workqueue (rather than scoped to a mount), butthe queued work is minimal.The final cleanup work for cleaning up a cfid is performed via workqueued in the serverclose_wq workqueue; this is done separate fromdropping the dentries so that close_all_cached_dirs() doesn't block onany server operations.Both of these queued works expect to invoked with a cfid reference anda tcon reference to avoid those objects from being freed while the workis ongoing.While we're here, add proper locking to close_all_cached_dirs(), andlocking around the freeing of cfid->dentry.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: Don't leak cfid when reconnect races with open_cached_diropen_cached_dir() may either race with the tcon reconnection even beforecompound_send_recv() or directly trigger a reconnection viaSMB2_open_init() or SMB_query_info_init().The reconnection process invokes invalidate_all_cached_dirs() viacifs_mark_open_files_invalid(), which removes all cfids from thecfids->entries list but doesn't drop a ref if has_lease isn't true. Thisresults in the currently-being-constructed cfid not being on the list,but still having a refcount of 2. It leaks if returned fromopen_cached_dir().Fix this by setting cfid->has_lease when the ref is actually taken; thecfid will not be used by other threads until it has a valid time.Addresses these kmemleaks:unreferenced object 0xffff8881090c4000 (size 1024): comm "bash", pid 1860, jiffies 4295126592 hex dump (first 32 bytes): 00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de ........"....... 00 ca 45 22 81 88 ff ff f8 dc 4f 04 81 88 ff ff ..E"......O..... backtrace (crc 6f58c20f): [] __kmalloc_cache_noprof+0x2be/0x350 [] open_cached_dir+0x993/0x1fb0 [] cifs_readdir+0x15a0/0x1d50 [] iterate_dir+0x28f/0x4b0 [] __x64_sys_getdents64+0xfd/0x200 [] do_syscall_64+0x95/0x1a0 [] entry_SYSCALL_64_after_hwframe+0x76/0x7eunreferenced object 0xffff8881044fdcf8 (size 8): comm "bash", pid 1860, jiffies 4295126592 hex dump (first 8 bytes): 00 cc cc cc cc cc cc cc ........ backtrace (crc 10c106a9): [] __kmalloc_node_track_caller_noprof+0x363/0x480 [] kstrdup+0x36/0x60 [] open_cached_dir+0x9b0/0x1fb0 [] cifs_readdir+0x15a0/0x1d50 [] iterate_dir+0x28f/0x4b0 [] __x64_sys_getdents64+0xfd/0x200 [] do_syscall_64+0x95/0x1a0 [] entry_SYSCALL_64_after_hwframe+0x76/0x7eAnd addresses these BUG splats when unmounting the SMB filesystem:BUG: Dentry ffff888140590ba0{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs]WARNING: CPU: 3 PID: 3433 at fs/dcache.c:1536 umount_check+0xd0/0x100Modules linked in:CPU: 3 UID: 0 PID: 3433 Comm: bash Not tainted 6.12.0-rc4-g850925a8133c-dirty #49Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020RIP: 0010:umount_check+0xd0/0x100Code: 8d 7c 24 40 e8 31 5a f4 ff 49 8b 54 24 40 41 56 49 89 e9 45 89 e8 48 89 d9 41 57 48 89 de 48 c7 c7 80 e7 db ac e8 f0 72 9a ff <0f> 0b 58 31 c0 5a 5b 5d 41 5c 41 5d 41 5e 41 5f e9 2b e5 5d 01 41RSP: 0018:ffff88811cc27978 EFLAGS: 00010286RAX: 0000000000000000 RBX: ffff888140590ba0 RCX: ffffffffaaf20baeRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881f6fb6f40RBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed1023984ee3R10: ffff88811cc2771f R11: 00000000016cfcc0 R12: ffff888134383e08R13: 0000000000000002 R14: ffff8881462ec668 R15: ffffffffaceab4c0FS: 00007f23bfa98740(0000) GS:ffff8881f6f80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000556de4a6f808 CR3: 0000000123c80000 CR4: 0000000000350ef0Call Trace: d_walk+0x6a/0x530 shrink_dcache_for_umount+0x6a/0x200 generic_shutdown_super+0x52/0x2a0 kill_anon_super+0x22/0x40 cifs_kill_sb+0x159/0x1e0 deactivate_locked_super+0x66/0xe0 cleanup_mnt+0x140/0x210 task_work_run+0xfb/0x170 syscall_exit_to_user_mode+0x29f/0x2b0 do_syscall_64+0xa1/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7f23bfb93ae7Code: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 0d 11 93 0d 00 f7 d8 64 89 01 b8 ff ff ff ff eb bf 0f 1f 44 00 00 b8 50 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 92 0d 00 f7 d8 64 89 ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: IDLETIMER: Fix for possible ABBA deadlockDeletion of the last rule referencing a given idletimer may happen atthe same time as a read of its file in sysfs:| ======================================================| WARNING: possible circular locking dependency detected| 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted| ------------------------------------------------------| iptables/3303 is trying to acquire lock:| ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20|| but task is already holding lock:| ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v]|| which lock already depends on the new lock.A simple reproducer is:| #!/bin/bash|| while true; do| iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"| iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"| done &| while true; do| cat /sys/class/xt_idletimer/timers/testme >/dev/null| doneAvoid this by freeing list_mutex right after deleting the element fromthe list, then continuing with the teardown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cachefiles: Fix NULL pointer dereference in object->fileAt present, the object->file has the NULL pointer dereference problem inondemand-mode. The root cause is that the allocated fd and object->filelifetime are inconsistent, and the user-space invocation to anon_fd usesobject->file. Following is the process that triggers the issue: [write fd] [umount]cachefiles_ondemand_fd_write_iter fscache_cookie_state_machine cachefiles_withdraw_cookie if (!file) return -ENOBUFS cachefiles_clean_up_object cachefiles_unmark_inode_in_use fput(object->file) object->file = NULL // file NULL pointer dereference! __cachefiles_write(..., file, ...)Fix this issue by add an additional reference count to the object->filebefore write/llseek, and decrement after it finished.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/arm-smmu: Defer probe of clients after smmu device boundNull pointer dereference occurs due to a race between smmudriver probe and client driver probe, when of_dma_configure()for client is called after the iommu_device_register() for smmu driverprobe has executed but before the driver_bound() for smmu driverhas been called.Following is how the race occurs:T1:Smmu device probe T2: Client device probereally_probe()arm_smmu_device_probe()iommu_device_register() really_probe() platform_dma_configure() of_dma_configure() of_dma_configure_id() of_iommu_configure() iommu_probe_device() iommu_init_device() arm_smmu_probe_device() arm_smmu_get_by_fwnode() driver_find_device_by_fwnode() driver_find_device() next_device() klist_next() /* null ptr assigned to smmu */ /* null ptr dereference while smmu->streamid_mask */driver_bound() klist_add_tail()When this null smmu pointer is dereferenced later inarm_smmu_probe_device, the device crashes.Fix this by deferring the probe of the client deviceuntil the smmu device has bound to the arm smmu driver.[will: Add comment]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:leds: class: Protect brightness_show() with led_cdev->led_access mutexThere is NULL pointer issue observed if from Process A where hid devicebeing added which results in adding a led_cdev addition and later aanother call to access of led_cdev attribute from Process B can resultin NULL pointer issue.Use mutex led_cdev->led_access to protect access to led->cdev and itsattribute inside brightness_show() and max_brightness_show() and alsoupdate the comment for mutex that it should be used to protect the ledclass device fields. Process A Process B kthread+0x114 worker_thread+0x244 process_scheduled_works+0x248 uhid_device_add_worker+0x24 hid_add_device+0x120 device_add+0x268 bus_probe_device+0x94 device_initial_probe+0x14 __device_attach+0xfc bus_for_each_drv+0x10c __device_attach_driver+0x14c driver_probe_device+0x3c __driver_probe_device+0xa0 really_probe+0x190 hid_device_probe+0x130 ps_probe+0x990 ps_led_register+0x94 devm_led_classdev_register_ext+0x58 led_classdev_register_ext+0x1f8 device_create_with_groups+0x48 device_create_groups_vargs+0xc8 device_add+0x244 kobject_uevent+0x14 kobject_uevent_env[jt]+0x224 mutex_unlock[jt]+0xc4 __mutex_unlock_slowpath+0xd4 wake_up_q+0x70 try_to_wake_up[jt]+0x48c preempt_schedule_common+0x28 __schedule+0x628 __switch_to+0x174 el0t_64_sync+0x1a8/0x1ac el0t_64_sync_handler+0x68/0xbc el0_svc+0x38/0x68 do_el0_svc+0x1c/0x28 el0_svc_common+0x80/0xe0 invoke_syscall+0x58/0x114 __arm64_sys_read+0x1c/0x2c ksys_read+0x78/0xe8 vfs_read+0x1e0/0x2c8 kernfs_fop_read_iter+0x68/0x1b4 seq_read_iter+0x158/0x4ec kernfs_seq_show+0x44/0x54 sysfs_kf_seq_show+0xb4/0x130 dev_attr_show+0x38/0x74 brightness_show+0x20/0x4c dualshock4_led_get_brightness+0xc/0x74[ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060[ 3313.874301][ T4013] Mem abort info:[ 3313.874303][ T4013] ESR = 0x0000000096000006[ 3313.874305][ T4013] EC = 0x25: DABT (current EL), IL = 32 bits[ 3313.874307][ T4013] SET = 0, FnV = 0[ 3313.874309][ T4013] EA = 0, S1PTW = 0[ 3313.874311][ T4013] FSC = 0x06: level 2 translation fault[ 3313.874313][ T4013] Data abort info:[ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000[ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000..[ 3313.874332][ T4013] Dumping ftrace buffer:[ 3313.874334][ T4013] (ftrace buffer empty)....[ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader[ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74[ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60[ 3313.874656][ T4013] sp : ffffffc0b910bbd0....[ 3313.874685][ T4013] Call trace:[ 3313.874687][ T4013] dualshock4_led_get_brightness+0xc/0x74[ 3313.874690][ T4013] brightness_show+0x20/0x4c[ 3313.874692][ T4013] dev_attr_show+0x38/0x74[ 3313.874696][ T4013] sysfs_kf_seq_show+0xb4/0x130[ 3313.874700][ T4013] kernfs_seq_show+0x44/0x54[ 3313.874703][ T4013] seq_read_iter+0x158/0x4ec[ 3313.874705][ T4013] kernfs_fop_read_iter+0x68/0x1b4[ 3313.874708][ T4013] vfs_read+0x1e0/0x2c8[ 3313.874711][ T4013] ksys_read+0x78/0xe8[ 3313.874714][ T4013] __arm64_sys_read+0x1c/0x2c[ 3313.874718][ T4013] invoke_syscall+0x58/0x114[ 3313.874721][ T4013] el0_svc_common+0x80/0xe0[ 3313.874724][ T4013] do_el0_svc+0x1c/0x28[ 3313.874727][ T4013] el0_svc+0x38/0x68[ 3313.874730][ T4013] el0t_64_sync_handler+0x68/0xbc[ 3313.874732][ T4013] el0t_64_sync+0x1a8/0x1ac
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcsan: Turn report_filterlist_lock into a raw_spinlockRan Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can seesplats like:| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48| in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1| preempt_count: 10002, expected: 0| RCU nest depth: 0, expected: 0| no locks held by swapper/1/0.| irq event stamp: 156674| hardirqs last enabled at (156673): [] do_idle+0x1f9/0x240| hardirqs last disabled at (156674): [] sysvec_apic_timer_interrupt+0x14/0xc0| softirqs last enabled at (0): [] copy_process+0xfc7/0x4b60| softirqs last disabled at (0): [<0000000000000000>] 0x0| Preemption disabled at:| [] paint_ptr+0x2a/0x90| CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014| Call Trace:| | dump_stack_lvl+0x7e/0xc0| dump_stack+0x1d/0x30| __might_resched+0x1a2/0x270| rt_spin_lock+0x68/0x170| kcsan_skip_report_debugfs+0x43/0xe0| print_report+0xb5/0x590| kcsan_report_known_origin+0x1b1/0x1d0| kcsan_setup_watchpoint+0x348/0x650| __tsan_unaligned_write1+0x16d/0x1d0| hrtimer_interrupt+0x3d6/0x430| __sysvec_apic_timer_interrupt+0xe8/0x3a0| sysvec_apic_timer_interrupt+0x97/0xc0| On a detected data race, KCSAN's reporting logic checks if it shouldfilter the report. That list is protected by the report_filterlist_lock*non-raw* spinlock which may sleep on RT kernels.Since KCSAN may report data races in any context, convert it to araw_spinlock.This requires being careful about when to allocate memory for the filterlist itself which can be done via KCSAN's debugfs interface. Concurrentmodification of the filter list via debugfs should be rare: the chosenstrategy is to optimistically pre-allocate memory before the criticalsection and discard if unused.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: Hold module reference while requesting a moduleUser space may unload ip_set.ko while it is itself requesting a set typebackend module, leading to a kernel crash. The race condition may beprovoked by inserting an mdelay() right after the nfnl_unlock() call.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointerConsidering that in some extreme cases,when u_serial driver is accessed by multiple threads,Thread A is executing the open operation and calling the gs_open,Thread B is executing the disconnect operation and calling thegserial_disconnect function,The port->port_usb pointer will be set to NULL.E.g. Thread A Thread B gs_open() gadget_unbind_driver() gs_start_io() composite_disconnect() gs_start_rx() gserial_disconnect() ... ... spin_unlock(&port->port_lock) status = usb_ep_queue() spin_lock(&port->port_lock) spin_lock(&port->port_lock) port->port_usb = NULL gs_free_requests(port->port_usb->in) spin_unlock(&port->port_lock) CrashThis causes thread A to access a null pointer (port->port_usb is null)when calling the gs_free_requests function, causing a crash.If port_usb is NULL, the release request will be skipped as itwill be done by gserial_disconnect.So add a null pointer check to gs_start_io before attemptingto access the value of the pointer port->port_usb.Call trace: gs_start_io+0x164/0x25c gs_open+0x108/0x13c tty_open+0x314/0x638 chrdev_open+0x1b8/0x258 do_dentry_open+0x2c4/0x700 vfs_open+0x2c/0x3c path_openat+0xa64/0xc60 do_filp_open+0xb8/0x164 do_sys_openat2+0x84/0xf0 __arm64_sys_openat+0x70/0x9c invoke_syscall+0x58/0x114 el0_svc_common+0x80/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x38/0x68
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: wl128x: Fix atomicity violation in fmc_send_cmd()Atomicity violation occurs when the fmc_send_cmd() function is executedsimultaneously with the modification of the fmdev->resp_skb value.Consider a scenario where, after passing the validity check within thefunction, a non-null fmdev->resp_skb variable is assigned a null value.This results in an invalid fmdev->resp_skb variable passing the validitycheck. As seen in the later part of the function, skb = fmdev->resp_skb;when the invalid fmdev->resp_skb passes the check, a null pointerdereference error may occur at line 478, evt_hdr = (void *)skb->data;To address this issue, it is recommended to include the validity check offmdev->resp_skb within the locked section of the function. Thismodification ensures that the value of fmdev->resp_skb does not changeduring the validation process, thereby maintaining its validity.This possible bug is found by an experimental static analysis tooldeveloped by our team. This tool analyzes the locking APIsto extract function pairs that can be concurrently executed, and thenanalyzes the instructions in the paired functions to identify possibleconcurrency bugs including data races and atomicity violations.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: atomisp: Add check for rgby_data memory allocation failureIn ia_css_3a_statistics_allocate(), there is no check on the allocationresult of the rgby_data memory. If rgby_data is not successfullyallocated, it may trigger the assert(host_stats->rgby_data) assertion inia_css_s3a_hmem_decode(). Adding a check to fix this potential issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.cAdd error pointer check after calling otx2_mbox_get_rsp().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: GNU GRUB (aka GRUB2) through 2.12 does not use a constant-time algorithm for grub_crypto_memcmp and thus allows side-channel attacks.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- grub2 > 0-0 (version in image is 2.06-150500.29.65.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:quota: flush quota_release_work upon quota writebackOne of the paths quota writeback is called from is:freeze_super() sync_filesystem() ext4_sync_fs() dquot_writeback_dquots()Since we currently don't always flush the quota_release_work queue inthis path, we can end up with the following race: 1. dquot are added to releasing_dquots list during regular operations. 2. FS Freeze starts, however, this does not flush the quota_release_work queue. 3. Freeze completes. 4. Kernel eventually tries to flush the workqueue while FS is frozen which hits a WARN_ON since transaction gets started during frozen state: ext4_journal_check_start+0x28/0x110 [ext4] (unreliable) __ext4_journal_start_sb+0x64/0x1c0 [ext4] ext4_release_dquot+0x90/0x1d0 [ext4] quota_release_workfn+0x43c/0x4d0Which is the following line: WARN_ON(sb->s_writers.frozen == SB_FREEZE_COMPLETE);Which ultimately results in generic/390 failing due to dmesgnoise. This was detected on powerpc machine 15 cores.To avoid this, make sure to flush the workqueue duringdquot_writeback_dquots() so we dont have any pending workitems afterfreeze.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: don't auto enable misc vectorCurrently, there is a time window between misc irq enabledand service task inited. If an interrupte is reported atthis time, it will cause warning like below:[ 16.324639] Call trace:[ 16.324641] __queue_delayed_work+0xb8/0xe0[ 16.324643] mod_delayed_work_on+0x78/0xd0[ 16.324655] hclge_errhand_task_schedule+0x58/0x90 [hclge][ 16.324662] hclge_misc_irq_handle+0x168/0x240 [hclge][ 16.324666] __handle_irq_event_percpu+0x64/0x1e0[ 16.324667] handle_irq_event+0x80/0x170[ 16.324670] handle_fasteoi_edge_irq+0x110/0x2bc[ 16.324671] __handle_domain_irq+0x84/0xfc[ 16.324673] gic_handle_irq+0x88/0x2c0[ 16.324674] el1_irq+0xb8/0x140[ 16.324677] arch_cpu_idle+0x18/0x40[ 16.324679] default_idle_call+0x5c/0x1bc[ 16.324682] cpuidle_idle_call+0x18c/0x1c4[ 16.324684] do_idle+0x174/0x17c[ 16.324685] cpu_startup_entry+0x30/0x6c[ 16.324687] secondary_start_kernel+0x1a4/0x280[ 16.324688] ---[ end trace 6aa0bff672a964aa ]---So don't auto enable misc vector when request irq..
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: make get_first_thin use rcu-safe list first functionThe documentation in rculist.h explains the absence of list_empty_rcu()and cautions programmers against relying on a list_empty() ->list_first() sequence in RCU safe code. This is because each of thesefunctions performs its own READ_ONCE() of the list head. This can leadto a situation where the list_empty() sees a valid list entry, but thesubsequent list_first() sees a different view of list head state after amodification.In the case of dm-thin, this author had a production box crash from a GPfault in the process_deferred_bios path. This function saw a valid listhead in get_first_thin() but when it subsequently dereferenced that andturned it into a thin_c, it got the inside of the struct pool, since thelist was now empty and referring to itself. The kernel on which thisoccurred printed both a warning about a refcount_t being saturated, anda UBSAN error for an out-of-bounds cpuid access in the queued spinlock,prior to the fault itself. When the resulting kdump was examined, itwas possible to see another thread patiently waiting in thin_dtr'ssynchronize_rcu.The thin_dtr call managed to pull the thin_c out of the active thinslist (and have it be the last entry in the active_thins list) at justthe wrong moment which lead to this crash.Fortunately, the fix here is straight forward. Switch get_first_thin()function to use list_first_or_null_rcu() which performs just a singleREAD_ONCE() and returns NULL if the list is already empty.This was run against the devicemapper test suite's thin-provisioningsuites for delete and suspend and no regressions were observed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: discard packets if the transport changesIf the socket has been de-assigned or assigned to another transport,we must discard any packets received because they are not expectedand would cause issues when we access vsk->transport.A possible scenario is described by Hyunwoo Kim in the attached link,where after a first connect() interrupted by a signal, and a secondconnect() failed, we can find `vsk->transport` at NULL, leading to aNULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eth: bnxt: always recalculate features after XDP clearing, fix null-derefRecalculate features when XDP is detached.Before: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: off [requested on]After: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: onThe fact that HW-GRO doesn't get re-enabled automatically is justa minor annoyance. The real issue is that the features will randomlycome back during another reconfiguration which just happens to invokenetdev_update_features(). The driver doesn't handle reconfiguringtwo things at a time very robustly.Starting with commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in__bnxt_reserve_rings()") we only reconfigure the RSS hash tableif the "effective" number of Rx rings has changed. If HW-GRO isenabled "effective" number of rings is 2x what user sees.So if we are in the bad state, with HW-GRO re-enablement "pending"after XDP off, and we lower the rings by / 2 - the HW-GRO ringsdoing 2x and the ethtool -L doing / 2 may cancel each other out,and the: if (old_rx_rings != bp->hw_resc.resv_rx_rings &&condition in __bnxt_reserve_rings() will be false.The RSS map won't get updated, and we'll crash with: BUG: kernel NULL pointer dereference, address: 0000000000000168 RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0 bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180 __bnxt_setup_vnic_p5+0x58/0x110 bnxt_init_nic+0xb72/0xf50 __bnxt_open_nic+0x40d/0xab0 bnxt_open_nic+0x2b/0x60 ethtool_set_channels+0x18c/0x1d0As we try to access a freed ring.The issue is present since XDP support was added, really, butprior to commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in__bnxt_reserve_rings()") it wasn't causing major issues.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: xilinx: Convert gpio_lock to raw spinlockirq_chip functions may be called in raw spinlock context. Therefore, wemust also use a raw spinlock for our own internal locking.This fixes the following lockdep splat:[ 5.349336] =============================[ 5.353349] [ BUG: Invalid wait context ][ 5.357361] 6.13.0-rc5+ #69 Tainted: G W[ 5.363031] -----------------------------[ 5.367045] kworker/u17:1/44 is trying to lock:[ 5.371587] ffffff88018b02c0 (&chip->gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))[ 5.380079] other info that might help us debug this:[ 5.385138] context-{5:5}[ 5.387762] 5 locks held by kworker/u17:1/44:[ 5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204)[ 5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205)[ 5.411528] #2: ffffff880172c900 (&dev->mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006)[ 5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596)[ 5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614)[ 5.436472] stack backtrace:[ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69[ 5.448690] Tainted: [W]=WARN[ 5.451656] Hardware name: xlnx,zynqmp (DT)[ 5.455845] Workqueue: events_unbound deferred_probe_work_func[ 5.461699] Call trace:[ 5.464147] show_stack+0x18/0x24 C[ 5.467821] dump_stack_lvl (lib/dump_stack.c:123)[ 5.471501] dump_stack (lib/dump_stack.c:130)[ 5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176)[ 5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814)[ 5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)[ 5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))[ 5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345)[ 5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250)[ 5.497645] irq_startup (kernel/irq/chip.c:270)[ 5.501143] __setup_irq (kernel/irq/manage.c:1807)[ 5.504728] request_threaded_irq (kernel/irq/manage.c:2208)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: aggregator: protect driver attr handlers against module unloadBoth new_device_store and delete_device_store touch module globalresources (e.g. gpio_aggregator_lock). To prevent race conditions withmodule unload, a reference needs to be held.Add try_module_get() in these handlers.For new_device_store, this eliminates what appears to be the most dangerousscenario: if an id is allocated from gpio_aggregator_idr butplatform_device_register has not yet been called or completed, a concurrentmodule unload could fail to unregister/delete the device, leaving behind adangling platform device/GPIO forwarder. This can result in various issues.The following simple reproducer demonstrates these problems: #!/bin/bash while :; do # note: whether 'gpiochip0 0' exists or not does not matter. echo 'gpiochip0 0' > /sys/bus/platform/drivers/gpio-aggregator/new_device done & while :; do modprobe gpio-aggregator modprobe -r gpio-aggregator done & wait Starting with the following warning, several kinds of warnings will appear and the system may become unstable: ------------[ cut here ]------------ list_del corruption, ffff888103e2e980->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120 [...] RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120 [...] Call Trace: ? __list_del_entry_valid_or_report+0xa3/0x120 ? __warn.cold+0x93/0xf2 ? __list_del_entry_valid_or_report+0xa3/0x120 ? report_bug+0xe6/0x170 ? __irq_work_queue_local+0x39/0xe0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? __list_del_entry_valid_or_report+0xa3/0x120 gpiod_remove_lookup_table+0x22/0x60 new_device_store+0x315/0x350 [gpio_aggregator] kernfs_fop_write_iter+0x137/0x1f0 vfs_write+0x262/0x430 ksys_write+0x60/0xd0 do_syscall_64+0x6c/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: streamzap: fix race between device disconnection and urb callbackSyzkaller has reported a general protection fault at functionir_raw_event_store_with_filter(). This crash is caused by a NULL pointerdereference of dev->raw pointer, even though it is checked for NULL inthe same function, which means there is a race condition. It occurs dueto the incorrect order of actions in the streamzap_disconnect() function:rc_unregister_device() is called before usb_kill_urb(). The dev->rawpointer is freed and set to NULL in rc_unregister_device(), and onlyafter that usb_kill_urb() waits for in-progress requests to finish.If rc_unregister_device() is called while streamzap_callback() handler isnot finished, this can lead to accessing freed resources. Thusrc_unregister_device() should be called after usb_kill_urb().Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: zswap: fix crypto_free_acomp() deadlock in zswap_cpu_comp_dead()Currently, zswap_cpu_comp_dead() calls crypto_free_acomp() while holdingthe per-CPU acomp_ctx mutex. crypto_free_acomp() then holds scomp_lock(through crypto_exit_scomp_ops_async()).On the other hand, crypto_alloc_acomp_node() holds the scomp_lock (throughcrypto_scomp_init_tfm()), and then allocates memory. If the allocationresults in reclaim, we may attempt to hold the per-CPU acomp_ctx mutex.The above dependencies can cause an ABBA deadlock. For example in thefollowing scenario:(1) Task A running on CPU #1: crypto_alloc_acomp_node() Holds scomp_lock Enters reclaim Reads per_cpu_ptr(pool->acomp_ctx, 1)(2) Task A is descheduled(3) CPU #1 goes offline zswap_cpu_comp_dead(CPU #1) Holds per_cpu_ptr(pool->acomp_ctx, 1)) Calls crypto_free_acomp() Waits for scomp_lock(4) Task A running on CPU #2: Waits for per_cpu_ptr(pool->acomp_ctx, 1) // Read on CPU #1 DEADLOCKSince there is no requirement to call crypto_free_acomp() with the per-CPUacomp_ctx mutex held in zswap_cpu_comp_dead(), move it after the mutex isunlocked. Also move the acomp_request_free() and kfree() calls forconsistency and to avoid any potential sublte locking dependencies in thefuture.With this, only setting acomp_ctx fields to NULL occurs with the mutexheld. This is similar to how zswap_cpu_comp_prepare() only initializesacomp_ctx fields with the mutex held, after performing all allocationsbefore holding the mutex.Opportunistically, move the NULL check on acomp_ctx so that it takes placebefore the mutex dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix adapter NULL pointer dereference on rebootWith SRIOV enabled, idpf ends up calling into idpf_remove() twice.First via idpf_shutdown() and then again when idpf_remove() calls intosriov_disable(), because the VF devices use the idpf driver, hence thesame remove routine. When that happens, it is possible for the adapterto be NULL from the first call to idpf_remove(), leading to a NULLpointer dereference.echo 1 > /sys/class/net//device/sriov_numvfsrebootBUG: kernel NULL pointer dereference, address: 0000000000000020...RIP: 0010:idpf_remove+0x22/0x1f0 [idpf]...? idpf_remove+0x22/0x1f0 [idpf]? idpf_remove+0x1e4/0x1f0 [idpf]pci_device_remove+0x3f/0xb0device_release_driver_internal+0x19f/0x200pci_stop_bus_device+0x6d/0x90pci_stop_and_remove_bus_device+0x12/0x20pci_iov_remove_virtfn+0xbe/0x120sriov_disable+0x34/0xe0idpf_sriov_configure+0x58/0x140 [idpf]idpf_remove+0x1b9/0x1f0 [idpf]idpf_shutdown+0x12/0x30 [idpf]pci_device_shutdown+0x35/0x60device_shutdown+0x156/0x200...Replace the direct idpf_remove() call in idpf_shutdown() withidpf_vc_core_deinit() and idpf_deinit_dflt_mbx(), which performthe bulk of the cleanup, such as stopping the init task, freeing IRQs,destroying the vports and freeing the mailbox. This avoids the calls tosriov_disable() in addition to a small netdev cleanup, and destroyingworkqueues, which don't seem to be required on shutdown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pm: cpupower: bench: Prevent NULL dereference on malloc failureIf malloc returns NULL due to low memory, 'config' pointer can be NULL.Add a check to prevent NULL dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix mode1 reset crash issueIf HW scheduler hangs and mode1 reset is used to recover GPU, KFD signaluser space to abort the processes. After process abort exit, user queuesstill use the GPU to access system memory before h/w is reset while KFDcleanup worker free system memory and free VRAM.There is use-after-free race bug that KFD allocate and reuse the freedsystem memory, and user queue write to the same system memory to corruptthe data structure and cause driver crash.To fix this race, KFD cleanup worker terminate user queues, then flushreset_domain wq to wait for any GPU ongoing reset complete, and thenfree outstanding BOs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: harden block_group::bg_list against list_del() racesAs far as I can tell, these calls of list_del_init() on bg_list cannotrun concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(),as they are in transaction error paths and situations where the blockgroup is readonly.However, if there is any chance at all of racing with mark_bg_unused(),or a different future user of bg_list, better to be safe than sorry.Otherwise we risk the following interleaving (bg_list refcount in parens)T1 (some random op) T2 (btrfs_mark_bg_unused) !list_empty(&bg->bg_list); (1)list_del_init(&bg->bg_list); (1) list_move_tail (1)btrfs_put_block_group (0) btrfs_delete_unused_bgs bg = list_first_entry list_del_init(&bg->bg_list); btrfs_put_block_group(bg); (-1)Ultimately, this results in a broken ref count that hits zero one derefearly and the real final deref underflows the refcount, resulting in a WARNING.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix deadlock between rcu_tasks_trace and event_mutex.Fix the following deadlock:CPU A_free_event() perf_kprobe_destroy() mutex_lock(&event_mutex) perf_trace_event_unreg() synchronize_rcu_tasks_trace()There are several paths where _free_event() grabs event_mutexand calls sync_rcu_tasks_trace. Above is one such case.CPU Bbpf_prog_test_run_syscall() rcu_read_lock_trace() bpf_prog_run_pin_on_cpu() bpf_prog_load() bpf_tracing_func_proto() trace_set_clr_event() mutex_lock(&event_mutex)Delegate trace_set_clr_event() to workqueue to avoidsuch lock dependency.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: inftlcore: Add error check for inftl_read_oob()In INFTL_findwriteunit(), the return value of inftl_read_oob()need to be checked. A proper implementation can befound in INFTL_deleteblock(). The status will be set asSECTOR_IGNORE to break from the while-loop correctlyif the inftl_read_oob() fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm-bufio: don't schedule in atomic contextA BUG was reported as below when CONFIG_DEBUG_ATOMIC_SLEEP andtry_verify_in_tasklet are enabled.[ 129.444685][ T934] BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2421[ 129.444723][ T934] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 934, name: kworker/1:4[ 129.444740][ T934] preempt_count: 201, expected: 0[ 129.444756][ T934] RCU nest depth: 0, expected: 0[ 129.444781][ T934] Preemption disabled at:[ 129.444789][ T934] [] shrink_work+0x21c/0x248[ 129.445167][ T934] kernel BUG at kernel/sched/walt/walt_debug.c:16![ 129.445183][ T934] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP[ 129.445204][ T934] Skip md ftrace buffer dump for: 0x1609e0[ 129.447348][ T934] CPU: 1 PID: 934 Comm: kworker/1:4 Tainted: G W OE 6.6.56-android15-8-o-g6f82312b30b9-debug #1 1400000003000000474e5500b3187743670464e8[ 129.447362][ T934] Hardware name: Qualcomm Technologies, Inc. Parrot QRD, Alpha-M (DT)[ 129.447373][ T934] Workqueue: dm_bufio_cache shrink_work[ 129.447394][ T934] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 129.447406][ T934] pc : android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug][ 129.447435][ T934] lr : __traceiter_android_rvh_schedule_bug+0x44/0x6c[ 129.447451][ T934] sp : ffffffc0843dbc90[ 129.447459][ T934] x29: ffffffc0843dbc90 x28: ffffffffffffffff x27: 0000000000000c8b[ 129.447479][ T934] x26: 0000000000000040 x25: ffffff804b3d6260 x24: ffffffd816232b68[ 129.447497][ T934] x23: ffffff805171c5b4 x22: 0000000000000000 x21: ffffffd816231900[ 129.447517][ T934] x20: ffffff80306ba898 x19: 0000000000000000 x18: ffffffc084159030[ 129.447535][ T934] x17: 00000000d2b5dd1f x16: 00000000d2b5dd1f x15: ffffffd816720358[ 129.447554][ T934] x14: 0000000000000004 x13: ffffff89ef978000 x12: 0000000000000003[ 129.447572][ T934] x11: ffffffd817a823c4 x10: 0000000000000202 x9 : 7e779c5735de9400[ 129.447591][ T934] x8 : ffffffd81560d004 x7 : 205b5d3938373434 x6 : ffffffd8167397c8[ 129.447610][ T934] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffffffc0843db9e0[ 129.447629][ T934] x2 : 0000000000002f15 x1 : 0000000000000000 x0 : 0000000000000000[ 129.447647][ T934] Call trace:[ 129.447655][ T934] android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug 1400000003000000474e550080cce8a8a78606b6][ 129.447681][ T934] __might_resched+0x190/0x1a8[ 129.447694][ T934] shrink_work+0x180/0x248[ 129.447706][ T934] process_one_work+0x260/0x624[ 129.447718][ T934] worker_thread+0x28c/0x454[ 129.447729][ T934] kthread+0x118/0x158[ 129.447742][ T934] ret_from_fork+0x10/0x20[ 129.447761][ T934] Code: ???????? ???????? ???????? d2b5dd1f (d4210000)[ 129.447772][ T934] ---[ end trace 0000000000000000 ]---dm_bufio_lock will call spin_lock_bh when try_verify_in_taskletis enabled, and __scan will be called in atomic context.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Add job to pending list if the reset was skippedWhen a CL/CSD job times out, we check if the GPU has made any progresssince the last timeout. If so, instead of resetting the hardware, we skipthe reset and let the timer get rearmed. This gives long-running jobs achance to complete.However, when `timedout_job()` is called, the job in question is removedfrom the pending list, which means it won't be automatically freed through`free_job()`. Consequently, when we skip the reset and keep the jobrunning, the job won't be freed when it finally completes.This situation leads to a memory leak, as exposed in [1] and [2].Similarly to commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler whenGPU is still active"), this patch ensures the job is put back on thepending list when extending the timeout.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:qibfs: fix _another_ leakfailure to allocate inode => leaked dentry...this one had been there since the initial merge; to be fair,if we are that far OOM, the odds of failing at that particularallocation are low...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notifyDuring our test, it is found that a warning can be trigger in try_grab_folioas follow: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]---Digging into the source, context->notify_page may init by get_user_pages_fastand can be seen in vmci_ctx_unset_notify which will try to put_page. Howeverget_user_pages_fast is not finished here and lead to followingtry_grab_folio warning. The race condition is shown as follow:cpu0 cpu1vmci_host_do_set_notifyvmci_host_setup_notifyget_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page);lockless_pages_from_mmgup_pgd_rangegup_huge_pmd // update &context->notify_page vmci_host_do_set_notify vmci_ctx_unset_notify notify_page = context->notify_page; if (notify_page) put_page(notify_page); // page is freed__gup_longterm_locked__get_user_pagesfollow_trans_huge_pmdtry_grab_folio // warn hereTo slove this, use local variable page to make notify_page can be seenafter finish get_user_pages_fast.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Kill timer properly at removalThe USB-audio MIDI code initializes the timer, but in a rare case, thedriver might be freed without the disconnect call. This leaves thetimer in an active state while the assigned object is released viasnd_usbmidi_free(), which ends up with a kernel warning when the debugconfiguration is enabled, as spotted by fuzzer.For avoiding the problem, put timer_shutdown_sync() atsnd_usbmidi_free(), so that the timer can be killed properly.While we're at it, replace the existing timer_delete_sync() at thedisconnect callback with timer_shutdown_sync(), too.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: ets: fix a race in ets_qdisc_change()Gerrard Tai reported a race condition in ETS, whenever SFQ perturb timerfires at the wrong time.The race is as follows:CPU 0 CPU 1[1]: lock root[2]: qdisc_tree_flush_backlog()[3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() |[4]: qdisc_put()This can be abused to underflow a parent's qlen.Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()should fix the race, because all packets will be purged from the qdiscbefore releasing the lock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: red: fix a race in __red_change()Gerrard Tai reported a race condition in RED, whenever SFQ perturb timerfires at the wrong time.The race is as follows:CPU 0 CPU 1[1]: lock root[2]: qdisc_tree_flush_backlog()[3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() |[4]: qdisc_put()This can be abused to underflow a parent's qlen.Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()should fix the race, because all packets will be purged from the qdiscbefore releasing the lock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix TOCTOU issue in sk_is_readable()sk->sk_prot->sock_is_readable is a valid function pointer when sk residesin a sockmap. After the last sk_psock_put() (which usually happens whensocket is removed from sockmap), sk->sk_prot gets restored andsk->sk_prot->sock_is_readable becomes NULL.This makes sk_is_readable() racy, if the value of sk->sk_prot is reloadedafter the initial check. Which in turn may lead to a null pointerdereference.Ensure the function pointer does not turn NULL after the check.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: make sure that ptp_rate is not 0 before configuring ESTIf the ptp_rate recorded earlier in the driver happens to be 0, thisbogus value will propagate up to EST configuration, where it willtrigger a division by 0.Prevent this division by 0 by adding the corresponding check and errorcode.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: make sure that ptp_rate is not 0 before configuring timestampingThe stmmac platform drivers that do not open-code the clk_ptp_rate valueafter having retrieved the default one from the device-tree can end upwith 0 in clk_ptp_rate (as clk_get_rate can return 0). It willeventually propagate up to PTP initialization when bringing up theinterface, leading to a divide by 0: Division by zero in kernel. CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.30-00001-g48313bd5768a #22 Hardware name: STM32 (Device Tree Support) Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x6c/0x8c dump_stack_lvl from Ldiv0_64+0x8/0x18 Ldiv0_64 from stmmac_init_tstamp_counter+0x190/0x1a4 stmmac_init_tstamp_counter from stmmac_hw_setup+0xc1c/0x111c stmmac_hw_setup from __stmmac_open+0x18c/0x434 __stmmac_open from stmmac_open+0x3c/0xbc stmmac_open from __dev_open+0xf4/0x1ac __dev_open from __dev_change_flags+0x1cc/0x224 __dev_change_flags from dev_change_flags+0x24/0x60 dev_change_flags from ip_auto_config+0x2e8/0x11a0 ip_auto_config from do_one_initcall+0x84/0x33c do_one_initcall from kernel_init_freeable+0x1b8/0x214 kernel_init_freeable from kernel_init+0x24/0x140 kernel_init from ret_from_fork+0x14/0x28 Exception stack(0xe0815fb0 to 0xe0815ff8)Prevent this division by 0 by adding an explicit check and error logabout the actual issue. While at it, remove the same check fromstmmac_ptp_register, which then becomes duplicate
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: Fix null-ptr-deref in jfs_ioc_trim[ Syzkaller Report ]Oops: general protection fault, probably for non-canonical address0xdffffc0000000087: 0000 [#1KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f]CPU: 2 UID: 0 PID: 10614 Comm: syz-executor.0 Not tainted6.13.0-rc6-gfbfd64d25c7a-dirty #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Sched_ext: serialise (enabled+all), task: runnable_at=-30msRIP: 0010:jfs_ioc_trim+0x34b/0x8f0Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 9390 82 fe ff 4c 89 ff 31 f6RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000aRDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:? __die_body+0x61/0xb0? die_addr+0xb1/0xe0? exc_general_protection+0x333/0x510? asm_exc_general_protection+0x26/0x30? jfs_ioc_trim+0x34b/0x8f0jfs_ioctl+0x3c8/0x4f0? __pfx_jfs_ioctl+0x10/0x10? __pfx_jfs_ioctl+0x10/0x10__se_sys_ioctl+0x269/0x350? __pfx___se_sys_ioctl+0x10/0x10? do_syscall_64+0xfb/0x210do_syscall_64+0xee/0x210? syscall_exit_to_user_mode+0x1e0/0x330entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fe51f4903adCode: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 4889 f7 48 89 d6 48 89 ca 4dRSP: 002b:00007fe5202250c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007fe51f5cbf80 RCX: 00007fe51f4903adRDX: 0000000020000680 RSI: 00000000c0185879 RDI: 0000000000000005RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640R13: 000000000000000e R14: 00007fe51f44fca0 R15: 00007fe52021d000Modules linked in:---[ end trace 0000000000000000 ]---RIP: 0010:jfs_ioc_trim+0x34b/0x8f0Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 9390 82 fe ff 4c 89 ff 31 f6RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000aRDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Kernel panic - not syncing: Fatal exception[ Analysis ]We believe that we have found a concurrency bug in the `fs/jfs` modulethat results in a null pointer dereference. There is a closely relatedissue which has been fixed:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234... but, unfortunately, the accepted patch appears to still besusceptible to a null pointer dereference under some interleavings.To trigger the bug, we think that `JFS_SBI(ipbmap->i_sb)->bmap` is setto NULL in `dbFreeBits` and then dereferenced in `jfs_ioc_trim`. Thisbug manifests quite rarely under normal circumstances, but istriggereable from a syz-program.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: Initialize ssc before laundromat_work to prevent NULL dereferenceIn nfs4_state_start_net(), laundromat_work may access nfsd_ssc throughnfs4_laundromat -> nfsd4_ssc_expire_umount. If nfsd_ssc isn't initialized,this can cause NULL pointer dereference.Normally the delayed start of laundromat_work allows sufficient time fornfsd_ssc initialization to complete. However, when the kernel waits toolong for userspace responses (e.g. in nfs4_state_start_net ->nfsd4_end_grace -> nfsd4_record_grace_done -> nfsd4_cld_grace_done ->cld_pipe_upcall -> __cld_pipe_upcall -> wait_for_completion path), thedelayed work may start before nfsd_ssc initialization finishes.Fix this by moving nfsd_ssc initialization before starting laundromat_work.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential deadlock when reconnecting channelsFix cifs_signal_cifsd_for_reconnect() to take the correct lock orderand prevent the following deadlock from happening======================================================WARNING: possible circular locking dependency detected6.16.0-rc3-build2+ #1301 Tainted: G S W------------------------------------------------------cifsd/6055 is trying to acquire lock:ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200but task is already holding lock:ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #2 (&ret_buf->chan_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_setup_session+0x81/0x4b0 cifs_get_smb_ses+0x771/0x900 cifs_mount_get_session+0x7e/0x170 cifs_mount+0x92/0x2d0 cifs_smb3_do_mount+0x161/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e-> #1 (&ret_buf->ses_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_match_super+0x101/0x320 sget+0xab/0x270 cifs_smb3_do_mount+0x1e0/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e-> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}: check_noncircular+0x95/0xc0 check_prev_add+0x115/0x2f0 validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_signal_cifsd_for_reconnect+0x134/0x200 __cifs_reconnect+0x8f/0x500 cifs_handle_standard+0x112/0x280 cifs_demultiplex_thread+0x64d/0xbc0 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30other info that might help us debug this:Chain exists of: &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ret_buf->chan_lock); lock(&ret_buf->ses_lock); lock(&ret_buf->chan_lock); lock(&tcp_ses->srv_lock); *** DEADLOCK ***3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200 #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200 #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister().syzbot reported a warning below during atm_dev_register(). [0]Before creating a new device and procfs/sysfs for it, atm_dev_register()looks up a duplicated device by __atm_dev_lookup(). These operations aredone under atm_dev_mutex.However, when removing a device in atm_dev_deregister(), it releases themutex just after removing the device from the list that __atm_dev_lookup()iterates over.So, there will be a small race window where the device does not exist onthe device list but procfs/sysfs are still not removed, triggering thesplat.Let's hold the mutex until procfs/sysfs are removed inatm_dev_deregister().[0]:proc_dir_entry 'atm/atmtcp:0' already registeredWARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377Modules linked in:CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 <0f> 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444FS: 00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: proc_create_data+0xbe/0x110 fs/proc/generic.c:585 atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361 atm_dev_register+0x46d/0x890 net/atm/resources.c:113 atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369 atmtcp_attach drivers/atm/atmtcp.c:403 [inline] atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x115/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f38b3b74459Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702fR10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0acR13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Fix use-after-free in vhci_flush()syzbot reported use-after-free in vhci_flush() without repro. [0]From the splat, a thread close()d a vhci file descriptor whileits device was being used by iotcl() on another thread.Once the last fd refcnt is released, vhci_release() callshci_unregister_dev(), hci_free_dev(), and kfree() for structvhci_data, which is set to hci_dev->dev->driver_data.The problem is that there is no synchronisation after unlinkinghdev from hci_dev_list in hci_unregister_dev(). There might beanother thread still accessing the hdev which was fetched beforethe unlink operation.We can use SRCU for such synchronisation.Let's run hci_dev_reset() under SRCU and wait for its completionin hci_unregister_dev().Another option would be to restore hci_dev->destruct(), which wasremoved in commit 587ae086f6e4 ("Bluetooth: Remove unusedhci-destruct cb"). However, this would not be a good solution, aswe should not run hci_unregister_dev() while there are in-flightioctl() requests, which could lead to another data-race KCSAN splat.Note that other drivers seem to have the same problem, for exmaple,virtbt_remove().[0]:BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fcf5b98e929Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 do_open fs/namei.c:3887 [inline] path_openat+0x2ee5/0x3830 fs/name---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix node corruption in ar->arvifs listIn current WLAN recovery code flow, ath11k_core_halt() onlyreinitializes the "arvifs" list head. This will cause thelist node immediately following the list head to become aninvalid list node. Because the prev of that node still pointsto the list head "arvifs", but the next of the list head "arvifs"no longer points to that list node.When a WLAN recovery occurs during the execution of a vifremoval, and it happens before the spin_lock_bh(&ar->data_lock)in ath11k_mac_op_remove_interface(), list_del() will detect thepreviously mentioned situation, thereby triggering a kernel panic.The fix is to remove and reinitialize all vif list nodes from thelist head "arvifs" during WLAN halt. The reinitialization is to makethe list nodes valid, ensuring that the list_del() inath11k_mac_op_remove_interface() can execute normally.Call trace:__list_del_entry_valid_or_report+0xb8/0xd0ath11k_mac_op_remove_interface+0xb0/0x27c [ath11k]drv_remove_interface+0x48/0x194 [mac80211]ieee80211_do_stop+0x6e0/0x844 [mac80211]ieee80211_stop+0x44/0x17c [mac80211]__dev_close_many+0xac/0x150__dev_change_flags+0x194/0x234dev_change_flags+0x24/0x6cdevinet_ioctl+0x3a0/0x670inet_ioctl+0x200/0x248sock_do_ioctl+0x60/0x118sock_ioctl+0x274/0x35c__arm64_sys_ioctl+0xac/0xf0invoke_syscall+0x48/0x114...Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/gpu: Fix crash when throttling GPU immediately during bootThere is a small chance that the GPU is already hot during boot. In thatcase, the call to of_devfreq_cooling_register() will immediately try toapply devfreq cooling, as seen in the following crash: Unable to handle kernel paging request at virtual address 0000000000014110 pc : a6xx_gpu_busy+0x1c/0x58 [msm] lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm] Call trace: a6xx_gpu_busy+0x1c/0x58 [msm] (P) devfreq_simple_ondemand_func+0x3c/0x150 devfreq_update_target+0x44/0xd8 qos_max_notifier_call+0x30/0x84 blocking_notifier_call_chain+0x6c/0xa0 pm_qos_update_target+0xd0/0x110 freq_qos_apply+0x3c/0x74 apply_constraint+0x88/0x148 __dev_pm_qos_update_request+0x7c/0xcc dev_pm_qos_update_request+0x38/0x5c devfreq_cooling_set_cur_state+0x98/0xf0 __thermal_cdev_update+0x64/0xb4 thermal_cdev_update+0x4c/0x58 step_wise_manage+0x1f0/0x318 __thermal_zone_device_update+0x278/0x424 __thermal_cooling_device_register+0x2bc/0x308 thermal_of_cooling_device_register+0x10/0x1c of_devfreq_cooling_register_power+0x240/0x2bc of_devfreq_cooling_register+0x14/0x20 msm_devfreq_init+0xc4/0x1a0 [msm] msm_gpu_init+0x304/0x574 [msm] adreno_gpu_init+0x1c4/0x2e0 [msm] a6xx_gpu_init+0x5c8/0x9c8 [msm] adreno_bind+0x2a8/0x33c [msm] ...At this point we haven't initialized the GMU at all yet, so we cannot readthe GMU registers inside a6xx_gpu_busy(). A similar issue was fixed beforein commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in6xx gpu_busy"): msm_devfreq_init() does call devfreq_suspend_device(), butunlike msm_devfreq_suspend(), it doesn't set the df->suspended flagaccordingly. This means the df->suspended flag does not match the actualdevfreq state after initialization and msm_devfreq_get_dev_status() willend up accessing GMU registers, causing the crash.Fix this by setting df->suspended correctly during initialization.Patchwork: https://patchwork.freedesktop.org/patch/650772/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/vmalloc: fix data race in show_numa_info()The following data-race was found in show_numa_info():==================================================================BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_showread to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....value changed: 0x0000008f -> 0x00000000==================================================================According to this report,there is a read/write data-race becausem->private is accessible to multiple CPUs. To fix this, instead ofallocating the heap in proc_vmalloc_init() and passing the heap address tom->private, vmalloc_info_show() should allocate the heap.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Initialize obj_event->obj_sub_list before xa_insertThe obj_event may be loaded immediately after inserted, then if thelist_head is not initialized then we may get a poisonous pointer. Thisfixes the crash below: mlx5_core 0000:03:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(2048) RxCqeCmprss(0 enhanced) mlx5_core.sf mlx5_core.sf.4: firmware version: 32.38.3056 mlx5_core 0000:03:00.0 en3f0pf0sf2002: renamed from eth0 mlx5_core.sf mlx5_core.sf.4: Rate limit: 127 rates are supported, range: 0Mbps to 195312Mbps IPv6: ADDRCONF(NETDEV_CHANGE): en3f0pf0sf2002: link becomes ready Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000007760fb000 [0000000000000060] pgd=000000076f6d7003, p4d=000000076f6d7003, pud=0000000777841003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] SMP Modules linked in: ipmb_host(OE) act_mirred(E) cls_flower(E) sch_ingress(E) mptcp_diag(E) udp_diag(E) raw_diag(E) unix_diag(E) tcp_diag(E) inet_diag(E) binfmt_misc(E) bonding(OE) rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) isofs(E) cdrom(E) mst_pciconf(OE) ib_umad(OE) mlx5_ib(OE) ipmb_dev_int(OE) mlx5_core(OE) kpatch_15237886(OEK) mlxdevm(OE) auxiliary(OE) ib_uverbs(OE) ib_core(OE) psample(E) mlxfw(OE) tls(E) sunrpc(E) vfat(E) fat(E) crct10dif_ce(E) ghash_ce(E) sha1_ce(E) sbsa_gwdt(E) virtio_console(E) ext4(E) mbcache(E) jbd2(E) xfs(E) libcrc32c(E) mmc_block(E) virtio_net(E) net_failover(E) failover(E) sha2_ce(E) sha256_arm64(E) nvme(OE) nvme_core(OE) gpio_mlxbf3(OE) mlx_compat(OE) mlxbf_pmc(OE) i2c_mlxbf(OE) sdhci_of_dwcmshc(OE) pinctrl_mlxbf3(OE) mlxbf_pka(OE) gpio_generic(E) i2c_core(E) mmc_core(E) mlxbf_gige(OE) vitesse(E) pwr_mlxbf(OE) mlxbf_tmfifo(OE) micrel(E) mlxbf_bootctl(OE) virtio_ring(E) virtio(E) ipmi_devintf(E) ipmi_msghandler(E) [last unloaded: mst_pci] CPU: 11 PID: 20913 Comm: rte-worker-11 Kdump: loaded Tainted: G OE K 5.10.134-13.1.an8.aarch64 #1 Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.2.2.12968 Oct 26 2023 pstate: a0400089 (NzCv daIf +PAN -UAO -TCO BTYPE=--) pc : dispatch_event_fd+0x68/0x300 [mlx5_ib] lr : devx_event_notifier+0xcc/0x228 [mlx5_ib] sp : ffff80001005bcf0 x29: ffff80001005bcf0 x28: 0000000000000001 x27: ffff244e0740a1d8 x26: ffff244e0740a1d0 x25: ffffda56beff5ae0 x24: ffffda56bf911618 x23: ffff244e0596a480 x22: ffff244e0596a480 x21: ffff244d8312ad90 x20: ffff244e0596a480 x19: fffffffffffffff0 x18: 0000000000000000 x17: 0000000000000000 x16: ffffda56be66d620 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000040 x10: ffffda56bfcafb50 x9 : ffffda5655c25f2c x8 : 0000000000000010 x7 : 0000000000000000 x6 : ffff24545a2e24b8 x5 : 0000000000000003 x4 : ffff80001005bd28 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff244e0596a480 x0 : ffff244d8312ad90 Call trace: dispatch_event_fd+0x68/0x300 [mlx5_ib] devx_event_notifier+0xcc/0x228 [mlx5_ib] atomic_notifier_call_chain+0x58/0x80 mlx5_eq_async_int+0x148/0x2b0 [mlx5_core] atomic_notifier_call_chain+0x58/0x80 irq_int_handler+0x20/0x30 [mlx5_core] __handle_irq_event_percpu+0x60/0x220 handle_irq_event_percpu+0x3c/0x90 handle_irq_event+0x58/0x158 handle_fasteoi_irq+0xfc/0x188 generic_handle_irq+0x34/0x48 ...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAINWe found a few different systems hung up in writeback waiting on the samepage lock, and one task waiting on the NFS_LAYOUT_DRAIN bit inpnfs_update_layout(), however the pnfs_layout_hdr's plh_outstanding countwas zero.It seems most likely that this is another race between the waiter and wakersimilar to commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task").Fix it up by applying the advised barrier.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: ims-pcu - check record size in ims_pcu_flash_firmware()The "len" variable comes from the firmware and we generally dotrust firmware, but it's always better to double check. If the "len"is too large it could result in memory corruption when we do"memcpy(fragment->data, rec->data, len);"
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/scheduler: signal scheduled fence when kill jobWhen an entity from application B is killed, drm_sched_entity_kill()removes all jobs belonging to that entity throughdrm_sched_entity_kill_jobs_work(). If application A's job depends on ascheduled fence from application B's job, and that fence is not properlysignaled during the killing process, application A's dependency cannot becleared.This leads to application A hanging indefinitely while waiting for adependency that will never be resolved. Fix this issue by ensuring thatscheduled fences are properly signaled when an entity is killed, allowingdependent applications to continue execution.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Fix transport_* TOCTOUTransport assignment may race with module unload. Protect new_transportfrom becoming a stale pointer.This also takes care of an insecure call in vsock_use_local_transport();add a lockdep assert.BUG: unable to handle page fault for address: fffffbfff8056000Oops: Oops: 0000 [#1] SMP KASANRIP: 0010:vsock_assign_transport+0x366/0x600Call Trace: vsock_connect+0x59c/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/exynos: exynos7_drm_decon: add vblank check in IRQ handlingIf there's support for another console device (such as a TTY serial),the kernel occasionally panics during boot. The panic message and arelevant snippet of the call stack is as follows: Unable to handle kernel NULL pointer dereference at virtual address 000000000000000 Call trace: drm_crtc_handle_vblank+0x10/0x30 (P) decon_irq_handler+0x88/0xb4 [...]Otherwise, the panics don't happen. This indicates that it's some sortof race condition.Add a check to validate if the drm device can handle vblanks beforecalling drm_crtc_handle_vblank() to avoid this.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb()syzbot reported null-ptr-deref in l2cap_sock_resume_cb(). [0]l2cap_sock_resume_cb() has a similar problem that was fixed by commit1bff51ea59a9 ("Bluetooth: fix use-after-free error in lock_sock_nested()").Since both l2cap_sock_kill() and l2cap_sock_resume_cb() are executedunder l2cap_sock_resume_cb(), we can avoid the issue simply by checkingif chan->data is NULL.Let's not access to the killed socket in l2cap_sock_resume_cb().[0]:BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline]BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPTHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Workqueue: hci0 hci_rx_workCall trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_report+0x58/0x84 mm/kasan/report.c:524 kasan_report+0xb0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189 __kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37 instrument_atomic_write include/linux/instrumented.h:82 [inline] clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357 hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline] hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514 hci_event_func net/bluetooth/hci_event.c:7511 [inline] hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565 hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070 process_one_work+0x7e8/0x155c kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3321 [inline] worker_thread+0x958/0xed8 kernel/workqueue.c:3402 kthread+0x5fc/0x75c kernel/kthread.c:464 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: zd1211rw: Fix potential NULL pointer dereference in zd_mac_tx_to_dev()There is a potential NULL pointer dereference in zd_mac_tx_to_dev(). Forexample, the following is possible: T0 T1zd_mac_tx_to_dev() /* len == skb_queue_len(q) */ while (len > ZD_MAC_MAX_ACK_WAITERS) { filter_ack() spin_lock_irqsave(&q->lock, flags); /* position == skb_queue_len(q) */ for (i=1; i
type == NL80211_IFTYPE_AP) skb = __skb_dequeue(q); spin_unlock_irqrestore(&q->lock, flags); skb_dequeue() -> NULLSince there is a small gap between checking skb queue length and skb beingunconditionally dequeued in zd_mac_tx_to_dev(), skb_dequeue() can return NULL.Then the pointer is passed to zd_mac_tx_status() where it is dereferenced.In order to avoid potential NULL pointer dereference due to situations likeabove, check if skb is not NULL before passing it to zd_mac_tx_status().Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/sched: Increment job count before swapping tail spsc queueA small race exists between spsc_queue_push and the run-job worker, inwhich spsc_queue_push may return not-first while the run-job worker hasalready idled due to the job count being zero. If this race occurs, jobscheduling stops, leading to hangs while waiting on the job's DMAfences.Seal this race by incrementing the job count before appending to theSPSC queue.This race was observed on a drm-tip 6.16-rc1 build with the Xe driver inan SVM test case.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Don't call mmput from MMU notifier callbackIf the process is exiting, the mmput inside mmu notifier callback fromcompactd or fork or numa balancing could release the last referenceof mm struct to call exit_mmap and free_pgtable, this triggers deadlockwith below backtrace.The deadlock will leak kfd process as mmu notifier release is not calledand cause VRAM leaking.The fix is to take mm reference mmget_non_zero when adding prange to thedeferred list to pair with mmput in deferred list work.If prange split and add into pchild list, the pchild work_item.mm is notused, so remove the mm parameter from svm_range_unmap_split andsvm_range_add_child.The backtrace of hung task: INFO: task python:348105 blocked for more than 64512 seconds. Call Trace: __schedule+0x1c3/0x550 schedule+0x46/0xb0 rwsem_down_write_slowpath+0x24b/0x4c0 unlink_anon_vmas+0xb1/0x1c0 free_pgtables+0xa9/0x130 exit_mmap+0xbc/0x1a0 mmput+0x5a/0x140 svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu] mn_itree_invalidate+0x72/0xc0 __mmu_notifier_invalidate_range_start+0x48/0x60 try_to_unmap_one+0x10fa/0x1400 rmap_walk_anon+0x196/0x460 try_to_unmap+0xbb/0x210 migrate_page_unmap+0x54d/0x7e0 migrate_pages_batch+0x1c3/0xae0 migrate_pages_sync+0x98/0x240 migrate_pages+0x25c/0x520 compact_zone+0x29d/0x590 compact_zone_order+0xb6/0xf0 try_to_compact_pages+0xbe/0x220 __alloc_pages_direct_compact+0x96/0x1a0 __alloc_pages_slowpath+0x410/0x930 __alloc_pages_nodemask+0x3a9/0x3e0 do_huge_pmd_anonymous_page+0xd7/0x3e0 __handle_mm_fault+0x5e3/0x5f0 handle_mm_fault+0xf7/0x2e0 hmm_vma_fault.isra.0+0x4d/0xa0 walk_pmd_range.isra.0+0xa8/0x310 walk_pud_range+0x167/0x240 walk_pgd_range+0x55/0x100 __walk_page_range+0x87/0x90 walk_page_range+0xf6/0x160 hmm_range_fault+0x4f/0x90 amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu] amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu] init_user_pages+0xb1/0x2a0 [amdgpu] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu] kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu] kfd_ioctl+0x29d/0x500 [amdgpu](cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: nbpfaxi: Fix memory corruption in probe()The nbpf->chan[] array is allocated earlier in the nbpf_probe() functionand it has "num_channels" elements. These three loops iterate oneelement farther than they should and corrupt memory.The changes to the second loop are more involved. In this case, we'recopying data from the irqbuf[] array into the nbpf->chan[] array. Ifthe data in irqbuf[i] is the error IRQ then we skip it, so the iteratorsare not in sync. I added a check to ensure that we don't go beyond theend of the irqbuf[] array. I'm pretty sure this can't happen, but itseemed harmless to add a check.On the other hand, after the loop has ended there is a check to ensurethat the "chan" iterator is where we expect it to be. In the originalcode we went one element beyond the end of the array so the iteratorwasn't in the correct place and it would always return -EINVAL. However,now it will always be in the correct place. I deleted the check sincewe know the result.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix bug due to prealloc collisionWhen userspace is using AF_RXRPC to provide a server, it has to preallocateincoming calls and assign to them call IDs that will be used to threadrelated recvmsg() and sendmsg() together. The preallocated call IDs willautomatically be attached to calls as they come in until the pool is empty.To the kernel, the call IDs are just arbitrary numbers, but userspace canuse the call ID to hold a pointer to prepared structs. In any case, theuser isn't permitted to create two calls with the same call ID (call IDsbecome available again when the call ends) and EBADSLT should result fromsendmsg() if an attempt is made to preallocate a call with an in-use callID.However, the cleanup in the error handling will trigger both assertions inrxrpc_cleanup_call() because the call isn't marked complete and isn'tmarked as having been released.Fix this by setting the call state in rxrpc_service_prealloc_one() and thenmarking it as being released before calling the cleanup function.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/eeh: Make EEH driver device hotplug safeMultiple race conditions existed between the PCIe hotplug driver and theEEH driver, leading to a variety of kernel oopses of the same generalnature:
A second class of oops is also seen when the underlying bus disappearsduring device recovery.Refactor the EEH module to be PCI rescan and remove safe. Also cleanup a few minor formatting / readability issues.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()'Function 'hci_discovery_filter_clear()' frees 'uuids' array and thensets it to NULL. There is a tiny chance of the following race:'hci_cmd_sync_work()' 'update_passive_scan_sync()' 'hci_update_passive_scan_sync()' 'hci_discovery_filter_clear()' kfree(uuids); <-------------------------preempted--------------------------------> 'start_service_discovery()' 'hci_discovery_filter_clear()' kfree(uuids); // DOUBLE FREE <-------------------------preempted--------------------------------> uuids = NULL;To fix it let's add locking around 'kfree()' call and NULL pointerassignment. Otherwise the following backtrace fires:[ ] ------------[ cut here ]------------[ ] kernel BUG at mm/slub.c:547![ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP[ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1[ ] Tainted: [O]=OOT_MODULE[ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ ] pc : __slab_free+0xf8/0x348[ ] lr : __slab_free+0x48/0x348...[ ] Call trace:[ ] __slab_free+0xf8/0x348[ ] kfree+0x164/0x27c[ ] start_service_discovery+0x1d0/0x2c0[ ] hci_sock_sendmsg+0x518/0x924[ ] __sock_sendmsg+0x54/0x60[ ] sock_write_iter+0x98/0xf8[ ] do_iter_readv_writev+0xe4/0x1c8[ ] vfs_writev+0x128/0x2b0[ ] do_writev+0xfc/0x118[ ] __arm64_sys_writev+0x20/0x2c[ ] invoke_syscall+0x68/0xf0[ ] el0_svc_common.constprop.0+0x40/0xe0[ ] do_el0_svc+0x1c/0x28[ ] el0_svc+0x30/0xd0[ ] el0t_64_sync_handler+0x100/0x12c[ ] el0t_64_sync+0x194/0x198[ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000)[ ] ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen: fix UAF in dmabuf_exp_from_pages()[dma_buf_fd() fixes; no preferences regarding the tree it goes through -up to xen folks]As soon as we'd inserted a file reference into descriptor table, anotherthread could close it. That's fine for the case when all we are doing isreturning that descriptor to userland (it's a race, but it's a userlandrace and there's nothing the kernel can do about it). However, if wefollow fd_install() with any kind of access to objects that would bedestroyed on close (be it the struct file itself or anything destroyedby its ->release()), we have a UAF.dma_buf_fd() is a combination of reserving a descriptor and fd_install().gntdev dmabuf_exp_from_pages() calls it and then proceeds to access theobjects destroyed on close - starting with gntdev_dmabuf itself.Fix that by doing reserving descriptor before anything else and dofd_install() only when everything had been set up.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: skbprio: Remove overly strict queue assertionsIn the current implementation, skbprio enqueue/dequeue contains an assertionthat fails under certain conditions when SKBPRIO is used as a child qdisc underTBF with specific parameters. The failure occurs because TBF sometimes peeks atpackets in the child qdisc without actually dequeuing them when tokens areunavailable.This peek operation creates a discrepancy between the parent and child qdiscqueue length counters. When TBF later receives a high-priority packet,SKBPRIO's queue length may show a different value than what's reflected in itsinternal priority queue tracking, triggering the assertion.The fix removes this overly strict assertions in SKBPRIO, they are notnecessary at all.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: remove mutex_lock check in hfsplus_free_extentsSyzbot reported an issue in hfsplus filesystem:------------[ cut here ]------------WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346 hfsplus_free_extents+0x700/0xad0Call Trace:hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56cont_expand_zero fs/buffer.c:2383 [inline]cont_write_begin+0x2cf/0x860 fs/buffer.c:2446hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263notify_change+0xe38/0x10f0 fs/attr.c:420do_truncate+0x1fb/0x2e0 fs/open.c:65do_sys_ftruncate+0x2eb/0x380 fs/open.c:193do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdTo avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlockon file truncation") unlock extree before hfsplus_free_extents(),and add check wheather extree is locked in hfsplus_free_extents().However, when operations such as hfsplus_file_release,hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executedconcurrently in different files, it is very likely to trigger theWARN_ON, which will lead syzbot and xfstest to consider it as anabnormality.The comment above this warning also describes one of the easytriggering situations, which can easily trigger and causexfstest&syzbot to report errors.[task A] [task B]->hfsplus_file_release ->hfsplus_file_truncate ->hfs_find_init ->mutex_lock ->mutex_unlock ->hfsplus_write_begin ->hfsplus_get_block ->hfsplus_file_extend ->hfsplus_ext_read_extent ->hfs_find_init ->mutex_lock ->hfsplus_free_extents WARN_ON(mutex_is_locked) !!!Several threads could try to lock the shared extents tree.And warning can be triggered in one thread when another threadhas locked the tree. This is the wrong behavior of the code andwe need to remove the warning.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Avoid stack buffer overflow from kernel cmdlineWhile the kernel command line is considered trusted in most environments,avoid writing 1 byte past the end of "acpiid" if the "str" argument ismaximum length.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structureIf a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, theresultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() mayoccur before sli4_hba.hdwqs are allocated. This may result in a nullpointer dereference when attempting to take the abts_io_buf_list_lock forthe first hardware queue. Fix by adding a null ptr check onphba->sli4_hba.hdwq and early return because this situation means theremust have been an error during port initialization.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: do not BUG when INLINE_DATA_FL lacks system.data xattrA syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data()when an inode had the INLINE_DATA_FL flag set but was missing thesystem.data extended attribute.Since this can happen due to a maiciouly fuzzed file system, weshouldn't BUG, but rather, report it as a corrupted file system.Add similar replacements of BUG_ON with EXT4_ERROR_INODE() iiext4_create_inline_data() and ext4_inline_data_truncate().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: l2cap: Check encryption key size on incoming connectionThis is required for passing GAP/SEC/SEM/BI-04-C PTS test case: Security Mode 4 Level 4, Responder - Invalid Encryption Key Size - 128 bitThis tests the security key with size from 1 to 15 bytes while theSecurity Mode 4 Level 4 requests 16 bytes key size.Currently PTS fails with the following logs:- expected:Connection Response: Code: [3 (0x03)] Code Identifier: (lt)WildCard: Exists(gt) Length: [8 (0x0008)] Destination CID: (lt)WildCard: Exists(gt) Source CID: [64 (0x0040)] Result: [3 (0x0003)] Connection refused - Security block Status: (lt)WildCard: Exists(gt),but received:Connection Response: Code: [3 (0x03)] Code Identifier: [1 (0x01)] Length: [8 (0x0008)] Destination CID: [64 (0x0040)] Source CID: [64 (0x0040)] Result: [0 (0x0000)] Connection Successful Status: [0 (0x0000)] No further information availableAnd HCI logs:< HCI Command: Read Encrypti.. (0x05|0x0008) plen 2 Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)> HCI Event: Command Complete (0x0e) plen 7 Read Encryption Key Size (0x05|0x0008) ncmd 1 Status: Success (0x00) Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) Key size: 7> ACL Data RX: Handle 14 flags 0x02 dlen 12 L2CAP: Connection Request (0x02) ident 1 len 4 PSM: 4097 (0x1001) Source CID: 64< ACL Data TX: Handle 14 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 1 len 8 Destination CID: 64 Source CID: 64 Result: Connection successful (0x0000) Status: No further information available (0x0000)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: Initialize the chan_stats array to zeroThe adapter->chan_stats[] array is initialized inmwifiex_init_channel_scan_gap() with vmalloc(), which doesn't zero outmemory. The array is filled in mwifiex_update_chan_statistics()and then the user can query the data in mwifiex_cfg80211_dump_survey().There are two potential issues here. What if the user callsmwifiex_cfg80211_dump_survey() before the data has been filled in.Also the mwifiex_update_chan_statistics() function doesn't necessarilyinitialize the whole array. Since the array was not initialized atthe start that could result in an information leak.Also this array is pretty small. It's a maximum of 900 bytes so it'smore appropriate to use kcalloc() instead vmalloc().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cgroup: split cgroup_destroy_wq into 3 workqueuesA hung task can occur during [1] LTP cgroup testing when repeatedlymounting/unmounting perf_event and net_prio controllers withsystemd.unified_cgroup_hierarchy=1. The hang manifests incgroup_lock_and_drain_offline() during root destruction.Related case:cgroup_fj_function_perf_event cgroup_fj_function.sh perf_eventcgroup_fj_function_net_prio cgroup_fj_function.sh net_prioCall Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20Root Cause:CPU0 CPU1mount perf_event umount net_priocgroup1_get_tree cgroup_kill_sbrebind_subsystems // root destruction enqueues // cgroup_destroy_wq// kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to dieProblem scenario:1. CPU0 mounts perf_event (rebind_subsystems)2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work3. A dying perf_event CSS gets queued for offline after root destruction4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)Solution:Split cgroup_destroy_wq into three dedicated workqueues:cgroup_offline_wq - Handles CSS offline operationscgroup_release_wq - Manages resource releasecgroup_free_wq - Performs final memory deallocationThis separation eliminates blocking in the CSS free path while waiting foroffline operations to complete.[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: fix folio is still mapped when deletedMigration may be raced with fallocating hole. remove_inode_single_foliowill unmap the folio if the folio is still mapped. However, it's calledwithout folio lock. If the folio is migrated and the mapped pte has beenconverted to migration entry, folio_mapped() returns false, and won'tunmap it. Due to extra refcount held by remove_inode_single_folio,migration fails, restores migration entry to normal pte, and the folio ismapped again. As a result, we triggered BUG in filemap_unaccount_folio.The log is as follows: BUG: Bad page cache in process hugetlb pfn:156c00 page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00 head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0 aops:hugetlbfs_aops ino:dcc dentry name(?):"my_hugepage_file" flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: f4(hugetlb) page dumped because: still mapped when deleted CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x4f/0x70 filemap_unaccount_folio+0xc4/0x1c0 __filemap_remove_folio+0x38/0x1c0 filemap_remove_folio+0x41/0xd0 remove_inode_hugepages+0x142/0x250 hugetlbfs_fallocate+0x471/0x5a0 vfs_fallocate+0x149/0x380Hold folio lock before checking if the folio is mapped to avold race withmigration.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix Use-after-free in validationNodes stored in the validation duplicates hashtable come from an arenaallocator that is cleared at the end of vmw_execbuf_process. All nodesare expected to be cleared in vmw_validation_drop_ht but this node escapedbecause its resource was destroyed prematurely.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm: fix NULL pointer dereference in __dm_suspend()There is a race condition between dm device suspend and table load thatcan lead to null pointer dereference. The issue occurs when suspend isinvoked before table load completes:BUG: kernel NULL pointer dereference, address: 0000000000000054Oops: 0000 [#1] PREEMPT SMP PTICPU: 6 PID: 6798 Comm: dmsetup Not tainted 6.6.0-g7e52f5f0ca9b #62Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014RIP: 0010:blk_mq_wait_quiesce_done+0x0/0x50Call Trace: blk_mq_quiesce_queue+0x2c/0x50 dm_stop_queue+0xd/0x20 __dm_suspend+0x130/0x330 dm_suspend+0x11a/0x180 dev_suspend+0x27e/0x560 ctl_ioctl+0x4cf/0x850 dm_ctl_ioctl+0xd/0x20 vfs_ioctl+0x1d/0x50 __se_sys_ioctl+0x9b/0xc0 __x64_sys_ioctl+0x19/0x30 x64_sys_call+0x2c4a/0x4620 do_syscall_64+0x9e/0x1b0The issue can be triggered as below:T1 T2dm_suspend table_load__dm_suspend dm_setup_md_queue dm_mq_init_request_queue blk_mq_init_allocated_queue => q->mq_ops = set->ops; (1)dm_stop_queue / dm_wait_for_completion=> q->tag_set NULL pointer! (2) => q->tag_set = set; (3)Fix this by checking if a valid table (map) exists before performingrequest-based suspend and waiting for target I/O. When map is NULL,skip these table-dependent suspend steps.Even when map is NULL, no I/O can reach any target because there isno table loaded; I/O submitted in this state will fail early in theDM layer. Skipping the table-dependent suspend logic in this caseis safe and avoids NULL pointer dereferences.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix potential deadlock while nr_requests grownAllocate and free sched_tags while queue is freezed can deadlock[1],this is a long term problem, hence allocate memory before freezingqueue and free memory after queue is unfreezed.[1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: Fix using smp_processor_id() in preemptible code warningsSyzbot reported the following warning:BUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879caller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary)Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49 usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708 usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417 __dev_set_mtu net/core/dev.c:9443 [inline] netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496 netif_set_mtu+0xb0/0x160 net/core/dev.c:9520 dev_set_mtu+0xae/0x170 net/core/dev_api.c:247 dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572 dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821 sock_do_ioctl+0x19d/0x280 net/socket.c:1204 sock_ioctl+0x42f/0x6a0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFor historical and portability reasons, the netif_rx() is usuallyrun in the softirq or interrupt context, this commit therefore addlocal_bh_disable/enable() protection in the usbnet_resume_rx().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/ip6_tunnel: Prevent perpetual tunnel growthSimilarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too.While ipv4 tunnel headroom adjustment growth was limited incommit 5ae1e9922bbd ("net: ip_tunnel: prevent perpetual headroom growth"),ipv6 tunnel yet increases the headroom without any ceiling.Reflect ipv4 tunnel headroom adjustment limit on ipv6 version.Credits to Francesco Ruggeri, who was originally debugging this issueand wrote local Arista-specific patch and a reproducer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request()The cpufreq_cpu_put() call in update_qos_request() takes place too earlybecause the latter subsequently calls freq_qos_update_request() thatindirectly accesses the policy object in question through the QoS requestobject passed to it.Fortunately, update_qos_request() is called under intel_pstate_driver_lock,so this issue does not matter for changing the intel_pstate operationmode, but it theoretically can cause a crash to occur on CPU device hotremoval (which currently can only happen in virt, but it is formallysupported nevertheless).Address this issue by modifying update_qos_request() to drop thereference to the policy later.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: client: fix memory leak in smb3_fs_context_parse_paramThe user calls fsconfig twice, but when the program exits, free() onlyfrees ctx->source for the second fsconfig, not the first.Regarding fc->source, there is no code in the fs context related to itsmemory reclamation.To fix this memory leak, release the source memory corresponding to ctxor fc before each parsing.syzbot reported:BUG: memory leakunreferenced object 0xffff888128afa360 (size 96): backtrace (crc 79c9c7ba): kstrdup+0x3c/0x80 mm/util.c:84 smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444BUG: memory leakunreferenced object 0xffff888112c7d900 (size 96): backtrace (crc 79c9c7ba): smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629 smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: delete radeon_fence_process in is_signaled, no deadlockDelete the attempt to progress the queue when checking if fence issignaled. This avoids deadlock.dma-fence_ops::signaled can be called with the fence lock in unknownstate. For radeon, the fence lock is also the wait queue lock. This cancause a self deadlock when signaled() tries to make forward progress onthe wait queue. But advancing the queue is unneeded because incorrectlyreturning false from signaled() is perfectly acceptable.(cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:page_pool: always add GFP_NOWARN for ATOMIC allocationsDriver authors often forget to add GFP_NOWARN for page allocationfrom the datapath. This is annoying to users as OOMs are a factof life, and we pretty much expect network Rx to hit page allocationfailures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocationsby default.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Clear cmds after chip resetCommit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handlingand host reset handling") caused two problems:1. Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.2. BUG_ON(cmd->sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in dma_unmap_sg_attrs().So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" andpartially revert "scsi: qla2xxx: target: Fix offline port handling andhost reset handling" at __qla2x00_abort_all_cmds.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: tegra210-quad: Fix timeout handlingWhen the CPU that the QSPI interrupt handler runs on (typically CPU 0)is excessively busy, it can lead to rare cases of the IRQ thread notrunning before the transfer timeout is reached.While handling the timeouts, any pending transfers are cleaned up andthe message that they correspond to is marked as failed, which leavesthe curr_xfer field pointing at stale memory.To avoid this, clear curr_xfer to NULL upon timeout and check for thiscondition when the IRQ thread is finally run.While at it, also make sure to clear interrupts on failure so that newinterrupts can be run.A better, more involved, fix would move the interrupt clearing into ahard IRQ handler. Ideally we would also want to signal that the IRQthread no longer needs to be run after the timeout is hit to avoid theextra check for a valid transfer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix missing hfs_bnode_get() in __hfs_bnode_createWhen sync() and link() are called concurrently, both threads mayenter hfs_bnode_find() without finding the node in the hash tableand proceed to create it.Thread A: hfsplus_write_inode() -> hfsplus_write_system_inode() -> hfs_btree_write() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0)Thread B: hfsplus_create_cat() -> hfs_brec_insert() -> hfs_bnode_split() -> hfs_bmap_alloc() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0)In this case, thread A creates the bnode, sets refcnt=1, and hashes it.Thread B also tries to create the same bnode, notices it has alreadybeen inserted, drops its own instance, and uses the hashed one withoutgetting the node.``` node2 = hfs_bnode_findhash(tree, cnid); if (!node2) { <- Thread A hash = hfs_bnode_hash(cnid); node->next_hash = tree->node_hash[hash]; tree->node_hash[hash] = node; tree->node_hash_cnt++; } else { <- Thread B spin_unlock(&tree->hash_lock); kfree(node); wait_event(node2->lock_wq, !test_bit(HFS_BNODE_NEW, &node2->flags)); return node2; }```However, hfs_bnode_find() requires each call to take a reference.Here both threads end up setting refcnt=1. When they later put the node,this triggers:BUG_ON(!atomic_read(&node->refcnt))In this scenario, Thread B in fact finds the node in the hash tablerather than creating a new one, and thus must take a reference.Fix this by calling hfs_bnode_get() when reusing a bnode newly created byanother thread to ensure the refcount is updated correctly.A similar bug was fixed in HFS long ago in commita9dc087fd3c4 ("fix missing hfs_bnode_get() in __hfs_bnode_create")but the same issue remained in HFS+ until now.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fsnotify: do not generate ACCESS/MODIFY events on child for special filesinotify/fanotify do not allow users with no read access to a file tosubscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow thesame user to subscribe for watching events on children when the userhas access to the parent directory (e.g. /dev).Users with no read access to a file but with read access to its parentdirectory can still stat the file and see if it was accessed/modifiedvia atime/mtime change.The same is not true for special files (e.g. /dev/null). Users will notgenerally observe atime/mtime changes when other users read/write tospecial files, only when someone sets atime/mtime via utimensat().Align fsnotify events with this stat behavior and do not generateACCESS/MODIFY events to parent watchers on read/write of special files.The events are still generated to parent watchers on utimensat(). Thiscloses some side-channels that could be possibly used for informationexfiltration [1].[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: xattr: fix null pointer deref in ext4_raw_inode()If ext4_get_inode_loc() fails (e.g. if it returns -EFSCORRUPTED),iloc.bh will remain set to NULL. Since ext4_xattr_inode_dec_ref_all()lacks error checking, this will lead to a null pointer dereferencein ext4_raw_inode(), called right after ext4_get_inode_loc().Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/mediatek: fix use-after-free on probe deferralThe driver is dropping the references taken to the larb devices duringprobe after successful lookup as well as on errors. This canpotentially lead to a use-after-free in case a larb device has not yetbeen bound to its driver so that the iommu driver probe defers.Fix this by keeping the references as expected while the iommu driver isbound.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: Fix reference count leak when using error routes with nexthop objectsWhen a nexthop object is deleted, it is marked as dead and thenfib_table_flush() is called to flush all the routes that are using thedead nexthop.The current logic in fib_table_flush() is to only flush error routes(e.g., blackhole) when it is called as part of network namespacedismantle (i.e., with flush_all=true). Therefore, error routes are notflushed when their nexthop object is deleted: # ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show blackhole 198.51.100.2 nhid 1 dev dummy1As such, they keep holding a reference on the nexthop object which inturn holds a reference on the nexthop device, resulting in a referencecount leak: # ip link del dev dummy1 [ 70.516258] unregister_netdevice: waiting for dummy1 to become free. Usage count = 2Fix by flushing error routes when their nexthop is marked as dead.IPv6 does not suffer from this problem.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KEYS: trusted: Fix a memory leak in tpm2_load_cmd'tpm2_load_cmd' allocates a tempoary blob indirectly via 'tpm2_key_decode'but it is not freed in the failure paths. Address this by wrapping the blobinto with a cleanup helper.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: rtl8150: fix memory leak on usb_submit_urb() failureIn async_set_registers(), when usb_submit_urb() fails, the allocated async_req structure and URB are not freed, causing a memory leak. The completion callback async_set_reg_cb() is responsible for freeing these allocations, but it is only called after the URB is successfully submitted and completes (successfully or with error). If submission fails, the callback never runs and the memory is leaked. Fix this by freeing both the URB and the request structure in the error path when usb_submit_urb() fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:phy: qcom-qusb2: Fix NULL pointer dereference on early suspendEnabling runtime PM before attaching the QPHY instance as driver datacan lead to a NULL pointer dereference in runtime PM callbacks thatexpect valid driver data. There is a small window where the suspendcallback may run after PM runtime enabling and before runtime forbid.This causes a sporadic crash during boot:```Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a1[...]CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.7+ #116 PREEMPTWorkqueue: pm pm_runtime_workpstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : qusb2_phy_runtime_suspend+0x14/0x1e0 [phy_qcom_qusb2]lr : pm_generic_runtime_suspend+0x2c/0x44[...]```Attach the QPHY instance as driver data before enabling runtime PM toprevent NULL pointer dereference in runtime PM callbacks.Reorder pm_runtime_enable() and pm_runtime_forbid() to prevent ashort window where an unnecessary runtime suspend can occur.Use the devres-managed version to ensure PM runtime is symmetricallydisabled during driver removal for proper cleanup.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix deadlock in wait_current_trans() due to ignored transaction typeWhen wait_current_trans() is called during start_transaction(), itcurrently waits for a blocked transaction without considering whetherthe given transaction type actually needs to wait for that particulartransaction state. The btrfs_blocked_trans_types[] array already defineswhich transaction types should wait for which transaction states, butthis check was missing in wait_current_trans().This can lead to a deadlock scenario involving two transactions andpending ordered extents: 1. Transaction A is in TRANS_STATE_COMMIT_DOING state 2. A worker processing an ordered extent calls start_transaction() with TRANS_JOIN 3. join_transaction() returns -EBUSY because Transaction A is in TRANS_STATE_COMMIT_DOING 4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes 5. A new Transaction B is created (TRANS_STATE_RUNNING) 6. The ordered extent from step 2 is added to Transaction B's pending ordered extents 7. Transaction B immediately starts commit by another task and enters TRANS_STATE_COMMIT_START 8. The worker finally reaches wait_current_trans(), sees Transaction B in TRANS_STATE_COMMIT_START (a blocked state), and waits unconditionally 9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START according to btrfs_blocked_trans_types[] 10. Transaction B is waiting for pending ordered extents to complete 11. Deadlock: Transaction B waits for ordered extent, ordered extent waits for Transaction BThis can be illustrated by the following call stacks: CPU0 CPU1 btrfs_finish_ordered_io() start_transaction(TRANS_JOIN) join_transaction() # -EBUSY (Transaction A is # TRANS_STATE_COMMIT_DOING) # Transaction A completes # Transaction B created # ordered extent added to # Transaction B's pending list btrfs_commit_transaction() # Transaction B enters # TRANS_STATE_COMMIT_START # waiting for pending ordered # extents wait_current_trans() # waits for Transaction B # (should not wait!)Task bstore_kv_sync in btrfs_commit_transaction waiting for orderedextents: __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfs_commit_transaction+0xbf7/0xda0 [btrfs] btrfs_sync_file+0x342/0x4d0 [btrfs] __x64_sys_fdatasync+0x4b/0x80 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9Task kworker in wait_current_trans waiting for transaction commit: Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs] __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 wait_current_trans+0xb0/0x110 [btrfs] start_transaction+0x346/0x5b0 [btrfs] btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs] btrfs_work_helper+0xe8/0x350 [btrfs] process_one_work+0x1d3/0x3c0 worker_thread+0x4d/0x3e0 kthread+0x12d/0x150 ret_from_fork+0x1f/0x30Fix this by passing the transaction type to wait_current_trans() andchecking btrfs_blocked_trans_types[cur_trans->state] against the giventype before deciding to wait. This ensures that transaction types whichare allowed to join during certain blocked states will not unnecessarilywait and cause deadlocks.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not free data reservation in fallback from inline due to -ENOSPCIf we fail to create an inline extent due to -ENOSPC, we will attempt togo through the normal COW path, reserve an extent, create an orderedextent, etc. However we were always freeing the reserved qgroup data,which is wrong since we will use data. Fix this by freeing the reservedqgroup data in __cow_file_range_inline() only if we are not doing thefallback (ret is <= 0).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: A flaw was found in libssh, a library that implements the SSH protocol. When calculating the session ID during the key exchange (KEX) process, an allocation failure in cryptographic functions may lead to a NULL pointer dereference. This issue can cause the client or server to crash.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libssh-config > 0-0 (version in image is 0.9.8-150400.3.17.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: Fix RSS LUT NULL pointer crash on early ethtool operationsThe RSS LUT is not initialized until the interface comes up, causingthe following NULL pointer crash when ethtool operations like rxhash on/offare performed before the interface is brought up for the first time.Move RSS LUT initialization from ndo_open to vport creation to ensure LUTis always available. This enables RSS configuration via ethtool beforebringing the interface up. Simplify LUT management by maintaining allchanges in the driver's soft copy and programming zeros to the indirectiontable when rxhash is disabled. Defer HW programming until the interfacecomes up if it is down during rxhash and LUT configuration changes.Steps to reproduce:** Load idpf driver; interfaces will be created modprobe idpf** Before bringing the interfaces up, turn rxhash off ethtool -K eth2 rxhash off[89408.371875] BUG: kernel NULL pointer dereference, address: 0000000000000000[89408.371908] #PF: supervisor read access in kernel mode[89408.371924] #PF: error_code(0x0000) - not-present page[89408.371940] PGD 0 P4D 0[89408.371953] Oops: Oops: 0000 [#1] SMP NOPTI[89408.372052] RIP: 0010:memcpy_orig+0x16/0x130[89408.372310] Call Trace:[89408.372317] [89408.372326] ? idpf_set_features+0xfc/0x180 [idpf][89408.372363] __netdev_update_features+0x295/0xde0[89408.372384] ethnl_set_features+0x15e/0x460[89408.372406] genl_family_rcv_msg_doit+0x11f/0x180[89408.372429] genl_rcv_msg+0x1ad/0x2b0[89408.372446] ? __pfx_ethnl_set_features+0x10/0x10[89408.372465] ? __pfx_genl_rcv_msg+0x10/0x10[89408.372482] netlink_rcv_skb+0x58/0x100[89408.372502] genl_rcv+0x2c/0x50[89408.372516] netlink_unicast+0x289/0x3e0[89408.372533] netlink_sendmsg+0x215/0x440[89408.372551] __sys_sendto+0x234/0x240[89408.372571] __x64_sys_sendto+0x28/0x30[89408.372585] x64_sys_call+0x1909/0x1da0[89408.372604] do_syscall_64+0x7a/0xfa0[89408.373140] ? clear_bhb_loop+0x60/0xb0[89408.373647] entry_SYSCALL_64_after_hwframe+0x76/0x7e[89408.378887]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: marvell: prestera: fix NULL dereference on devlink_alloc() failuredevlink_alloc() may return NULL on allocation failure, butprestera_devlink_alloc() unconditionally calls devlink_priv() onthe returned pointer.This leads to a NULL pointer dereference if devlink allocation fails.Add a check for a NULL devlink pointer and return NULL early to avoidthe crash.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: fix potential underflow in virtio_transport_get_credit()The credit calculation in virtio_transport_get_credit() uses unsignedarithmetic: ret = vvs->peer_buf_alloc - (vvs->tx_cnt - vvs->peer_fwd_cnt);If the peer shrinks its advertised buffer (peer_buf_alloc) while bytesare in flight, the subtraction can underflow and produce a largepositive value, potentially allowing more data to be queued than thepeer can handle.Reuse virtio_transport_has_space() which already handles this case andadd a comment to make it clear why we are doing that.[Stefano: use virtio_transport_has_space() instead of duplicating the code][Stefano: tweak the commit message]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_agThis is more of a preventive patch to make the code more consistent andto prevent possible exploits that employ child qlen manipulations on qfq.use cl_is_active instead of relying on the child qdisc's qlen to determineclass activation.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Wake up the error handler when final completions race against each otherThe fragile ordering between marking commands completed or failed sothat the error handler only wakes when the last running commandcompletes or times out has race conditions. These race conditions cancause the SCSI layer to fail to wake the error handler, leaving I/Othrough the SCSI host stuck as the error state cannot advance.First, there is an memory ordering issue within scsi_dec_host_busy().The write which clears SCMD_STATE_INFLIGHT may be reordered with readscounting in scsi_host_busy(). While the local CPU will see its ownwrite, reordering can allow other CPUs in scsi_dec_host_busy() orscsi_eh_inc_host_failed() to see a raised busy count, causing no CPU tosee a host busy equal to the host_failed count.This race condition can be prevented with a memory barrier on the errorpath to force the write to be visible before counting host busycommands.Second, there is a general ordering issue with scsi_eh_inc_host_failed(). Bycounting busy commands before incrementing host_failed, it can race with afinal command in scsi_dec_host_busy(), such that scsi_dec_host_busy() doesnot see host_failed incremented but scsi_eh_inc_host_failed() counts busycommands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(),resulting in neither waking the error handler task.This needs the call to scsi_host_busy() to be moved after host_failed isincremented to close the race condition.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: fix dma_free_coherent() pointerdma_alloc_coherent() allocates a DMA mapped buffer and stores theaddresses in XXX_unaligned fields. Those should be reused when freeingthe buffer rather than the aligned addresses.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: llcp: Fix memleak in nfc_llcp_send_ui_frame().syzbot reported various memory leaks related to NFC, structnfc_llcp_sock, sk_buff, nfc_dev, etc. [0]The leading log hinted that nfc_llcp_send_ui_frame() failedto allocate skb due to sock_error(sk) being -ENXIO.ENXIO is set by nfc_llcp_socket_release() when structnfc_llcp_local is destroyed by local_cleanup().The problem is that there is no synchronisation betweennfc_llcp_send_ui_frame() and local_cleanup(), and skbcould be put into local->tx_queue after it was purged inlocal_cleanup(): CPU1 CPU2 ---- ---- nfc_llcp_send_ui_frame() local_cleanup() |- do { ' |- pdu = nfc_alloc_send_skb(..., &err) | . | |- nfc_llcp_socket_release(local, false, ENXIO); | |- skb_queue_purge(&local->tx_queue); | | ' | |- skb_queue_tail(&local->tx_queue, pdu); | ... | |- pdu = nfc_alloc_send_skb(..., &err) | ^._________________________________.'local_cleanup() is called for struct nfc_llcp_local onlyafter nfc_llcp_remove_local() unlinks it from llcp_devices.If we hold local->tx_queue.lock then, we can synchronisethe thread and nfc_llcp_send_ui_frame().Let's do that and check list_empty(&local->list) beforequeuing skb to local->tx_queue in nfc_llcp_send_ui_frame().[0]:[ 56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6)[ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak)BUG: memory leakunreferenced object 0xffff8881272f6800 (size 1024): comm "syz.0.17", pid 6096, jiffies 4294942766 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc da58d84d): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] __do_kmalloc_node mm/slub.c:5645 [inline] __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658 kmalloc_noprof include/linux/slab.h:961 [inline] sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239 sk_alloc+0x36/0x360 net/core/sock.c:2295 nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979 llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044 nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31 __sock_create+0x1a9/0x340 net/socket.c:1605 sock_create net/socket.c:1663 [inline] __sys_socket_create net/socket.c:1700 [inline] __sys_socket+0xb9/0x1a0 net/socket.c:1747 __do_sys_socket net/socket.c:1761 [inline] __se_sys_socket net/socket.c:1759 [inline] __x64_sys_socket+0x1b/0x30 net/socket.c:1759 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fBUG: memory leakunreferenced object 0xffff88810fbd9800 (size 240): comm "syz.0.17", pid 6096, jiffies 4294942850 hex dump (first 32 bytes): 68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h....... 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/'.... backtrace (crc 6cc652b1): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336 __alloc_skb+0x203/0x240 net/core/skbuff.c:660 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0x69/0x3f0 net/core/sk---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Don't clobber irqfd routing type when deassigning irqfdWhen deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ'srouting entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, tohandle a concurrent routing update, verify that the irqfd is still activebefore consuming the routing information. As evidenced by the x86 andarm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below),clobbering the entry type without notifying arch code is surprising anderror prone.As a bonus, checking that the irqfd is active provides a convenientlocation for documenting _why_ KVM must not consume the routing entry foran irqfd that is in the process of being deassigned: once the irqfd isdeleted from the list (which happens *before* the eventfd is detached), itwill no longer receive updates via kvm_irq_routing_update(), and so KVMcould deliver an event using stale routing information (relative toKVM_SET_GSI_ROUTING returning to userspace).As an even better bonus, explicitly checking for the irqfd being activefixes a similar bug to the one the clobbering is trying to prevent: if anirqfd is deactivated, and then its routing is changed,kvm_irq_routing_update() won't invoke kvm_arch_update_irqfd_routing()(because the irqfd isn't in the list). And so if the irqfd is in bypassmode, IRQs will continue to be posted using the old routing information.As for kvm_arch_irq_bypass_del_producer(), clobbering the routing typeresults in KVM incorrectly keeping the IRQ in bypass mode, which isespecially problematic on AMD as KVM tracks IRQs that are being posted toa vCPU in a list whose lifetime is tied to the irqfd.Without the help of KASAN to detect use-after-free, the most commonsympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due tothe memory for irqfd structure being re-allocated and zeroed, resultingin irqfd->irq_bypass_data being NULL when read byavic_update_iommu_vcpu_affinity(): BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:amd_iommu_update_ga+0x19/0xe0 Call Trace: avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd] __avic_vcpu_load+0xf4/0x130 [kvm_amd] kvm_arch_vcpu_load+0x89/0x210 [kvm] vcpu_load+0x30/0x40 [kvm] kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm] kvm_vcpu_ioctl+0x571/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x6f/0x9d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46893b ---[ end trace 0000000000000000 ]---If AVIC is inhibited when the irfd is deassigned, the bug will manifest aslist corruption, e.g. on the next irqfd assignment. list_add corruption. next->prev should be prev (ffff8d474d5cd588), but was 0000000000000000. (next=ffff8d8658f86530). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:31! Oops: invalid opcode: 0000 [#1] SMP CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:__list_add_valid_or_report+0x97/0xc0 Call Trace: avic_pi_update_irte+0x28e/0x2b0 [kvm_amd] kvm_pi_update_irte+0xbf/0x190 [kvm] kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm] irq_bypass_register_consumer+0xcd/0x170 [irqbypa---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu()l3mdev_master_dev_rcu() can return NULL when the slave device is beingun-slaved from a VRF. All other callers deal with this, but we lostthe fallback to loopback in ip6_rt_pcpu_alloc() -> ip6_rt_get_dev_rcu()with commit 4832c30d5458 ("net: ipv6: put host and anycast routes ondevice with address"). KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418) Call Trace: ip6_pol_route (net/ipv6/route.c:2318) fib6_rule_lookup (net/ipv6/fib6_rules.c:115) ip6_route_output_flags (net/ipv6/route.c:2607) vrf_process_v6_outbound (drivers/net/vrf.c:437)I was tempted to rework the un-slaving code to clear the flag firstand insert synchronize_rcu() before we remove the upper. But looks likethe explicit fallback to loopback_dev is an established pattern.And I guess avoiding the synchronize_rcu() is nice, too.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: usb: etas_es58x: correctly anchor the urb in the read bulk callbackWhen submitting an urb, that is using the anchor pattern, it needs to beanchored before submitting it otherwise it could be leaked ifusb_kill_anchored_urbs() is called. This logic is correctly doneelsewhere in the driver, except in the read bulk callback so do thathere also.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boostingRunning stress-ng --schedpolicy 0 on an RT kernel on a big machinemight lead to the following WARNINGs (edited). sched: DL de-boosted task PID 22725: REPLENISH flag missing WARNING: CPU: 93 PID: 0 at kernel/sched/deadline.c:239 dequeue_task_dl+0x15c/0x1f8 ... (running_bw underflow) Call trace: dequeue_task_dl+0x15c/0x1f8 (P) dequeue_task+0x80/0x168 deactivate_task+0x24/0x50 push_dl_task+0x264/0x2e0 dl_task_timer+0x1b0/0x228 __hrtimer_run_queues+0x188/0x378 hrtimer_interrupt+0xfc/0x260 ...The problem is that when a SCHED_DEADLINE task (lock holder) ischanged to a lower priority class via sched_setscheduler(), it mayfail to properly inherit the parameters of potential DEADLINE donorsif it didn't already inherit them in the past (shorter deadline thandonor's at that time). This might lead to bandwidth accountingcorruption, as enqueue_task_dl() won't recognize the lock holder asboosted.The scenario occurs when:1. A DEADLINE task (donor) blocks on a PI mutex held by another DEADLINE task (holder), but the holder doesn't inherit parameters (e.g., it already has a shorter deadline)2. sched_setscheduler() changes the holder from DEADLINE to a lower class while still holding the mutex3. The holder should now inherit DEADLINE parameters from the donor and be enqueued with ENQUEUE_REPLENISH, but this doesn't happenFix the issue by introducing __setscheduler_dl_pi(), which detects whena DEADLINE (proper or boosted) task gets setscheduled to a lowerpriority class. In case, the function makes the task inherit DEADLINEparameters of the donoer (pi_se) and sets ENQUEUE_REPLENISH flag toensure proper bandwidth accounting during the next enqueue operation.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nf_tables: nft_dynset: fix possible stateful expression memleak in error pathIf cloning the second stateful expression in the element via GFP_ATOMICfails, then the first stateful expression remains in place without beingreleased. unreferenced object (percpu) 0x607b97e9cab8 (size 16): comm "softirq", pid 0, jiffies 4294931867 hex dump (first 16 bytes on cpu 3): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace (crc 0): pcpu_alloc_noprof+0x453/0xd80 nft_counter_clone+0x9c/0x190 [nf_tables] nft_expr_clone+0x8f/0x1b0 [nf_tables] nft_dynset_new+0x2cb/0x5f0 [nf_tables] nft_rhash_update+0x236/0x11c0 [nf_tables] nft_dynset_eval+0x11f/0x670 [nf_tables] nft_do_chain+0x253/0x1700 [nf_tables] nft_do_chain_ipv4+0x18d/0x270 [nf_tables] nf_hook_slow+0xaa/0x1e0 ip_local_deliver+0x209/0x330
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/logicvc: Fix device node reference leak in logicvc_drm_config_parse()The logicvc_drm_config_parse() function calls of_get_child_by_name() tofind the "layers" node but fails to release the reference, leading to adevice node reference leak.Fix this by using the __free(device_node) cleanup attribute to automaticrelease the reference when the variable goes out of scope.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM: runtime: Fix a race condition related to device removalThe following code in pm_runtime_work() may dereference the dev->parentpointer after the parent device has been freed: /* Maybe the parent is now able to suspend. */ if (parent && !parent->power.ignore_children) { spin_unlock(&dev->power.lock); spin_lock(&parent->power.lock); rpm_idle(parent, RPM_ASYNC); spin_unlock(&parent->power.lock); spin_lock(&dev->power.lock); }Fix this by inserting a flush_work() call in pm_runtime_remove().Without this patch blktest block/001 triggers the following complaintsporadically:BUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081Workqueue: pm pm_runtime_workCall Trace: dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x8b/0x310 print_report+0xfd/0x1d7 kasan_report+0xd8/0x1d0 __kasan_check_byte+0x42/0x60 lock_acquire.part.0+0x38/0x230 lock_acquire+0x70/0x160 _raw_spin_lock+0x36/0x50 rpm_suspend+0xc6a/0xfe0 rpm_idle+0x578/0x770 pm_runtime_work+0xee/0x120 process_one_work+0xde3/0x1410 worker_thread+0x5eb/0xfe0 kthread+0x37b/0x480 ret_from_fork+0x6cb/0x920 ret_from_fork_asm+0x11/0x20 Allocated by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_alloc_info+0x3d/0x50 __kasan_kmalloc+0xa0/0xb0 __kmalloc_noprof+0x311/0x990 scsi_alloc_target+0x122/0xb60 [scsi_mod] __scsi_scan_target+0x101/0x460 [scsi_mod] scsi_scan_channel+0x179/0x1c0 [scsi_mod] scsi_scan_host_selected+0x259/0x2d0 [scsi_mod] store_scan+0x2d2/0x390 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810 do_syscall_64+0xee/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53Freed by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_free_info+0x3f/0x50 __kasan_slab_free+0x67/0x80 kfree+0x225/0x6c0 scsi_target_dev_release+0x3d/0x60 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_dev_release+0xacf/0x12c0 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_put+0x7f/0xc0 [scsi_mod] sdev_store_delete+0xa5/0x120 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libblkid1 > 0-0 (version in image is 2.37.4-150500.9.26.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Fix memory leak when a wq is resetidxd_wq_disable_cleanup() which is called from the reset path for aworkqueue, sets the wq type to NONE, which for other parts of thedriver mean that the wq is empty (all its resources were released).Only set the wq type to NONE after its resources are released.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix use-after-free in update_super_work when racing with umountCommit b98535d09179 ("ext4: fix bug_on in start_this_handle during umountfilesystem") moved ext4_unregister_sysfs() before flushing s_sb_upd_workto prevent new error work from being queued via /proc/fs/ext4/xx/mb_groupsreads during unmount. However, this introduced a use-after-free becauseupdate_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() whichaccesses the kobject's kernfs_node after it has been freed by kobject_del()in ext4_unregister_sysfs(): update_super_work ext4_put_super ----------------- -------------- ext4_unregister_sysfs(sb) kobject_del(&sbi->s_kobj) __kobject_del() sysfs_remove_dir() kobj->sd = NULL sysfs_put(sd) kernfs_put() // RCU free ext4_notify_error_sysfs(sbi) sysfs_notify(&sbi->s_kobj) kn = kobj->sd // stale pointer kernfs_get(kn) // UAF on freed kernfs_node ext4_journal_destroy() flush_work(&sbi->s_sb_upd_work)Instead of reordering the teardown sequence, fix this by makingext4_notify_error_sysfs() detect that sysfs has already been torn downby checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() callin that case. A dedicated mutex (s_error_notify_mutex) serializesext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs()to prevent TOCTOU races where the kobject could be deleted between thestate_in_sysfs check and the sysfs_notify() call.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix drm_edid leak in amdgpu_dm[WHAT]When a sink is connected, aconnector->drm_edid was overwritten withoutfreeing the previous allocation, causing a memory leak on resume.[HOW]Free the previous drm_edid before updating it.(cherry picked from commit 52024a94e7111366141cfc5d888b2ef011f879e5)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix potential deadlock in cpu hotplug with osnoiseThe following sequence may leads deadlock in cpu hotplug: task1 task2 task3 ----- ----- ----- mutex_lock(&interface_lock) [CPU GOING OFFLINE] cpus_write_lock(); osnoise_cpu_die(); kthread_stop(task3); wait_for_completion(); osnoise_sleep(); mutex_lock(&interface_lock); cpus_read_lock(); [DEAD LOCK]Fix by swap the order of cpus_read_lock() and mutex_lock(&interface_lock).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/syscalls: Add spectre boundary for syscall dispatch tableThe s390 syscall number is directly controlled by userspace, but doesnot have an array_index_nospec() boundary to prevent access past thesyscall function pointer tables.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:esp: fix skb leak with espintcp and async cryptoWhen the TX queue for espintcp is full, esp_output_tail_tcp willreturn an error and not free the skb, because with synchronous crypto,the common xfrm output code will drop the packet for us.With async crypto (esp_output_done), we need to drop the skb whenesp_output_tail_tcp returns an error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: magicmouse: avoid memory leak in magicmouse_report_fixup()The magicmouse_report_fixup() function was returning anewly kmemdup()-allocated buffer, but never freeing it.The caller of report_fixup() does not take ownership of the returnedpointer, but it *is* permitted to return a sub-portion of the inputrdesc, whose lifetime is managed by the caller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: asus: avoid memory leak in asus_report_fixup()The asus_report_fixup() function was returning a newly allocatedkmemdup()-allocated buffer, but never freeing it. Switch todevm_kzalloc() to ensure the memory is managed and freed automaticallywhen the device is removed.The caller of report_fixup() does not take ownership of the returnedpointer, but it is permitted to return a pointer whose lifetime is atleast that of the input buffer.Also fix a harmless out-of-bounds read by copying only the originaldescriptor size.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: bcm: bcm2835-power: Increase ASB control timeoutThe bcm2835_asb_control() function uses a tight polling loop to waitfor the ASB bridge to acknowledge a request. During intensive workloads,this handshake intermittently fails for V3D's master ASB on BCM2711,resulting in "Failed to disable ASB master for v3d" errors duringruntime PM suspend. As a consequence, the failed power-off leaves V3D ina broken state, leading to bus faults or system hangs on later accesses.As the timeout is insufficient in some scenarios, increase the pollingtimeout from 1us to 5us, which is still negligible in the context of apower domain transition. Also, replace the open-coded ktime_get_ns()/cpu_relax() polling loop with readl_poll_timeout_atomic().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: uvc: fix NULL pointer dereference during unbind raceCommit b81ac4395bbe ("usb: gadget: uvc: allow for application to cleanlyshutdown") introduced two stages of synchronization waits totaling 1500msin uvc_function_unbind() to prevent several types of kernel panics.However, this timing-based approach is insufficient during powermanagement (PM) transitions.When the PM subsystem starts freezing user space processes, thewait_event_interruptible_timeout() is aborted early, which allows theunbind thread to proceed and nullify the gadget pointer(cdev->gadget = NULL):[ 814.123447][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind()[ 814.178583][ T3173] PM: suspend entry (deep)[ 814.192487][ T3173] Freezing user space processes[ 814.197668][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind no clean disconnect, wait for releaseWhen the PM subsystem resumes or aborts the suspend and tasks arerestarted, the V4L2 release path is executed and attempts to access thealready nullified gadget pointer, triggering a kernel panic:[ 814.292597][ C0] PM: pm_system_irq_wakeup: 479 triggered dhdpcie_host_wake[ 814.386727][ T3173] Restarting tasks ...[ 814.403522][ T4558] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030[ 814.404021][ T4558] pc : usb_gadget_deactivate+0x14/0xf4[ 814.404031][ T4558] lr : usb_function_deactivate+0x54/0x94[ 814.404078][ T4558] Call trace:[ 814.404080][ T4558] usb_gadget_deactivate+0x14/0xf4[ 814.404083][ T4558] usb_function_deactivate+0x54/0x94[ 814.404087][ T4558] uvc_function_disconnect+0x1c/0x5c[ 814.404092][ T4558] uvc_v4l2_release+0x44/0xac[ 814.404095][ T4558] v4l2_release+0xcc/0x130Address the race condition and NULL pointer dereference by:1. State Synchronization (flag + mutex)Introduce a 'func_unbound' flag in struct uvc_device. This allowsuvc_function_disconnect() to safely skip accessing the nullifiedcdev->gadget pointer. As suggested by Alan Stern, this flag is protectedby a new mutex (uvc->lock) to ensure proper memory ordering and preventinstruction reordering or speculative loads. This mutex is also used toprotect 'func_connected' for consistent state management.2. Explicit Synchronization (completion)Use a completion to synchronize uvc_function_unbind() with theuvc_vdev_release() callback. This prevents Use-After-Free (UAF) byensuring struct uvc_device is freed after all video device resourcesare released.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel/uncore: Fix die ID init and look up bugsIn snbep_pci2phy_map_init(), in the nr_node_ids > 8 path,uncore_device_to_die() may return -1 when all CPUs associatedwith the UBOX device are offline.Remove the WARN_ON_ONCE(die_id == -1) check for two reasons:- The current code breaks out of the loop. This is incorrect because pci_get_device() does not guarantee iteration in domain or bus order, so additional UBOX devices may be skipped during the scan.- Returning -EINVAL is incorrect, since marking offline buses with die_id == -1 is expected and should not be treated as an error.Separately, when NUMA is disabled on a NUMA-capable platform,pcibus_to_node() returns NUMA_NO_NODE, causing uncore_device_to_die()to return -1 for all PCI devices. As a result,spr_update_device_location(), used on Intel SPR and EMR, ignores thecorresponding PMON units and does not add them to the RB tree.Fix this by using uncore_pcibus_to_dieid(), which retrieves topologyfrom the UBOX GIDNIDMAP register and works regardless of whether NUMAis enabled in Linux. This requires snbep_pci2phy_map_init() to beadded in spr_uncore_pci_init().Keep uncore_device_to_die() only for the nr_node_ids > 8 case, whereNUMA is expected to be enabled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i3c: mipi-i3c-hci: Fix race in DMA ring dequeueThe HCI DMA dequeue path (hci_dma_dequeue_xfer()) may be invoked formultiple transfers that timeout around the same time. However, thefunction is not serialized and can race with itself.When a timeout occurs, hci_dma_dequeue_xfer() stops the ring, processesincomplete transfers, and then restarts the ring. If another timeouttriggers a parallel call into the same function, the two instances mayinterfere with each other - stopping or restarting the ring at unexpectedtimes.Add a mutex so that hci_dma_dequeue_xfer() is serialized with respect toitself.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: containerd is an open-source container runtime. A bug was found in containerd prior to versions 1.6.38, 1.7.27, and 2.0.4 where containers launched with a User set as a `UID:GID` larger than the maximum 32-bit signed integer can cause an overflow condition where the container ultimately runs as root (UID 0). This could cause unexpected behavior for environments that require containers to run as a non-root user. This bug has been fixed in containerd 1.6.38, 1.7.27, and 2.04. As a workaround, ensure that only trusted images are used and that only trusted users have permissions to import images.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- containerd > 0-0 (version in image is 1.7.29-150000.132.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdc-acm: Check control transfer buffer size before accessIf the first fragment is shorter than struct usb_cdc_notification, we can'tcalculate an expected_size. Log an error and discard the notificationinstead of reading lengths from memory outside the received data, which canlead to memory corruption when the expected_size decreases betweenfragments, causing `expected_size - acm->nb_index` to wrap.This issue has been present since the beginning of git history; however,it only leads to memory corruption since commit ea2583529cd1("cdc-acm: reassemble fragmented notifications").A mitigating factor is that acm_ctrl_irq() can only execute after userspacehas opened /dev/ttyACM*; but if ModemManager is running, ModemManager willdo that automatically depending on the USB device's vendor/product IDs andits other interfaces.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()Robert Morris reported:|If a malicious USB device pretends to be an Intersil p54 wifi|interface and generates an eeprom_readback message with a large|eeprom->v1.len, p54_rx_eeprom_readback() will copy data from the|message beyond the end of priv->eeprom.||static void p54_rx_eeprom_readback(struct p54_common *priv,| struct sk_buff *skb)|{| struct p54_hdr *hdr = (struct p54_hdr *) skb->data;| struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr->data;|| if (priv->fw_var >= 0x509) {| memcpy(priv->eeprom, eeprom->v2.data,| le16_to_cpu(eeprom->v2.len));| } else {| memcpy(priv->eeprom, eeprom->v1.data,| le16_to_cpu(eeprom->v1.len));| }| [...]The eeprom->v{1,2}.len is set by the driver in p54_download_eeprom().The device is supposed to provide the same length back to the driver.But yes, it's possible (like shown in the report) to alter the valueto something that causes a crash/panic due to overrun.This patch addresses the issue by adding the size to the common devicecontext, so p54_rx_eeprom_readback no longer relies on possibly tamperedvalues... That said, it also checks if the "firmware" altered the valueand no longer copies them.The one, small saving grace is: Before the driver tries to read the eeprom,it needs to upload >a< firmware. the vendor firmware has a proprietarylicense and as a reason, it is not present on most distributions bydefault.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: NFSv4 file creation neglects setting ACLAn NFSv4 client that sets an ACL with a named principal during filecreation retrieves the ACL afterwards, and finds that it is only adefault ACL (based on the mode bits) and not the ACL that wasrequested during file creation. This violates RFC 8881 section6.4.1.3: "the ACL attribute is set as given".The issue occurs in nfsd_create_setattr(), which callsnfsd_attrs_valid() to determine whether to call nfsd_setattr().However, nfsd_attrs_valid() checks only for iattr changes andsecurity labels, but not POSIX ACLs. When only an ACL is present,the function returns false, nfsd_setattr() is skipped, and thePOSIX ACL is never applied to the inode.Subsequently, when the client retrieves the ACL, the server findsno POSIX ACL on the inode and returns one generated from the file'smode bits rather than returning the originally-specified ACL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: reject new transactions if the fs is fully read-only[BUG]There is a bug report where a heavily fuzzed fs is mounted with allrescue mount options, which leads to the following warnings duringunmount: BTRFS: Transaction aborted (error -22) Modules linked in: CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted 6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline] RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611 Call Trace: btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705 btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157 btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517 btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708 btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130 btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499 btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628 evict+0x5f4/0xae0 fs/inode.c:837 __dentry_kill+0x209/0x660 fs/dcache.c:670 finish_dput+0xc9/0x480 fs/dcache.c:879 shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661 generic_shutdown_super+0x67/0x2c0 fs/super.c:621 kill_anon_super+0x3b/0x70 fs/super.c:1289 btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127 deactivate_locked_super+0xbc/0x130 fs/super.c:474 cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318 task_work_run+0x1d4/0x260 kernel/task_work.c:233 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x694/0x22f0 kernel/exit.c:971 do_group_exit+0x21c/0x2d0 kernel/exit.c:1112 __do_sys_exit_group kernel/exit.c:1123 [inline] __se_sys_exit_group kernel/exit.c:1121 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121 x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x44f639 Code: Unable to access opcode bytes at 0x44f60f. RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 Since rescue mount options will mark the full fs read-only, there shouldbe no new transaction triggered.But during unmount we will evict all inodes, which can trigger a newtransaction, and triggers warnings on a heavily corrupted fs.[CAUSE]Btrfs allows new transaction even on a read-only fs, this is to allowlog replay happen even on read-only mounts, just like what ext4/xfs do.However with rescue mount options, the fs is fully read-only and cannotbe remounted read-write, thus in that case we should also reject any newtransactions.[FIX]If we find the fs has rescue mount options, we should treat the fs aserror, so that no new transaction can be started.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: close race conditions on sk_receive_queuesk->sk_receive_queue is protected by skb queue lock, but for KCMsockets its RX path takes mux->rx_lock to protect more than justskb queue. However, kcm_recvmsg() still only grabs the skb queuelock, so race conditions still exist.We can teach kcm_recvmsg() to grab mux->rx_lock too but this wouldintroduce a potential performance regression as struct kcm_mux canbe shared by multiple KCM sockets.So we have to enforce skb queue lock in requeue_rx_msgs() and handleskb peek case carefully in kcm_wait_data(). Fortunately,skb_recv_datagram() already handles it nicely and is widely used byother sockets, we can just switch to skb_recv_datagram() aftergetting rid of the unnecessary sock lock in kcm_recvmsg() andkcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets,so it is safe to get rid of this check too.I ran the original syzbot reproducer for 30 min without seeing anyissue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: Vim is an open source command line text editor. When performing a search and displaying the search-count message is disabled (:set shm+=S), the search pattern is displayed at the bottom of the screen in a buffer (msgbuf). When right-left mode (:set rl) is enabled, the search pattern is reversed. This happens by allocating a new buffer. If the search pattern contains some ASCII NUL characters, the buffer allocated will be smaller than the original allocated buffer (because for allocating the reversed buffer, the strlen() function is called, which only counts until it notices an ASCII NUL byte ) and thus the original length indicator is wrong. This causes an overflow when accessing characters inside the msgbuf by the previously (now wrong) length of the msgbuf. The issue has been fixed as of Vim patch v9.1.0689.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- vim > 0-0 (version in image is 9.2.0280-150500.20.46.1).
-
Description: Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- vim > 0-0 (version in image is 9.2.0280-150500.20.46.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xsk: Fix race condition in AF_XDP generic RX pathMove rx_lock from xsk_socket to xsk_buff_pool.Fix synchronization for shared umem mode ingeneric RX path where multiple sockets sharesingle xsk_buff_pool.RX queue is exclusive to xsk_socket, while FILLqueue can be shared between multiple sockets.This could result in race condition where twoCPU cores access RX path of two different socketssharing the same umem.Protect both queues by acquiring spinlock in sharedxsk_buff_pool.Lock contention may be minimized in the future by someper-thread FQ buffering.It's safe and necessary to move spin_lock_bh(rx_lock)after xsk_rcv_check():* xs->pool and spinlock_init is synchronized by xsk_bind() -> xsk_is_bound() memory barriers.* xsk_rcv_check() may return true at the moment of xsk_release() or xsk_unbind_dev(), however this will not cause any data races or race conditions. xsk_unbind_dev() removes xdp socket from all maps and waits for completion of all outstanding rx operations. Packets in RX path will either complete safely or drop.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix panic when forwarding a pkt with no in6 devkongweibin reported a kernel panic in ip6_forward() when input interfacehas no in6 dev associated.The following tc commands were used to reproduce this panic:tc qdisc del dev vxlan100 roottc qdisc add dev vxlan100 root netem corrupt 5%
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspaceCall kvm_init() only after _all_ setup is complete, as kvm_init() exposes/dev/kvm to userspace and thus allows userspace to create VMs (and callother ioctls). E.g. KVM will encounter a NULL pointer when attempting toadd a vCPU to the per-CPU loaded_vmcss_on_cpu list if userspace is able tocreate a VM before vmx_init() configures said list. BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP CPU: 6 PID: 1143 Comm: stable Not tainted 6.0.0-rc7+ #988 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:vmx_vcpu_load_vmcs+0x68/0x230 [kvm_intel] vmx_vcpu_load+0x16/0x60 [kvm_intel] kvm_arch_vcpu_load+0x32/0x1f0 [kvm] vcpu_load+0x2f/0x40 [kvm] kvm_arch_vcpu_create+0x231/0x310 [kvm] kvm_vm_ioctl+0x79f/0xe10 [kvm] ? handle_mm_fault+0xb1/0x220 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x2b/0x50 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f5a6b05743b Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel(+) kvm irqbypass
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:coresight: cti: Fix hang in cti_disable_hw()cti_enable_hw() and cti_disable_hw() are called from an atomic contextso shouldn't use runtime PM because it can result in a sleep whencommunicating with firmware.Since commit 3c6656337852 ("Revert "firmware: arm_scmi: Add clockmanagement to the SCMI power domain""), this causes a hang on Juno whenrunning the Perf Coresight tests or running this command: perf record -e cs_etm//u -- lsThis was also missed until the revert commit because pm_runtime_put()was called with the wrong device until commit 692c9a499b28 ("coresight:cti: Correct the parameter for pm_runtime_put")With lock and scheduler debugging enabled the following is output: coresight cti_sys0: cti_enable_hw -- dev:cti_sys0 parent: 20020000.cti BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [] copy_process+0xa0c/0x1948 softirqs last enabled at (0): [] copy_process+0xa0c/0x1948 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022 Call trace: dump_backtrace+0x134/0x140 show_stack+0x20/0x58 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 __might_resched+0x180/0x228 __might_sleep+0x50/0x88 __pm_runtime_resume+0xac/0xb0 cti_enable+0x44/0x120 coresight_control_assoc_ectdev+0xc0/0x150 coresight_enable_path+0xb4/0x288 etm_event_start+0x138/0x170 etm_event_add+0x48/0x70 event_sched_in.isra.122+0xb4/0x280 merge_sched_in+0x1fc/0x3d0 visit_groups_merge.constprop.137+0x16c/0x4b0 ctx_sched_in+0x114/0x1f0 perf_event_sched_in+0x60/0x90 ctx_resched+0x68/0xb0 perf_event_exec+0x138/0x508 begin_new_exec+0x52c/0xd40 load_elf_binary+0x6b8/0x17d0 bprm_execve+0x360/0x7f8 do_execveat_common.isra.47+0x218/0x238 __arm64_sys_execve+0x48/0x60 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.4+0xfc/0x120 do_el0_svc+0x34/0xc0 el0_svc+0x40/0x98 el0t_64_sync_handler+0x98/0xc0 el0t_64_sync+0x170/0x174Fix the issue by removing the runtime PM calls completely. They are notneeded here because it must have already been done when building thepath for a trace.[ Fix build warnings ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: eeprom: fix null-deref on genl_info in dumpThe similar fix as commit 46cdedf2a0fa ("ethtool: pse-pd: fix null-deref ongenl_info in dump") is also needed for ethtool eeprom.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: ensure sane device mtu in tunnelsAnother syzbot report [1] with no reproducer hintsat a bug in ip6_gre tunnel (dev:ip6gretap0)Since ipv6 mcast code makes sure to read dev->mtu onceand applies a sanity check on it (see commit b9b312a7a451"ipv6: mcast: better catch silly mtu values"), a remainingpossibility is that a layer is able to set dev->mtu toan underflowed value (high order bit set).This could happen indeed in ip6gre_tnl_link_config_route(),ip6_tnl_link_config() and ipip6_tunnel_bind_dev()Make sure to sanitize mtu value in a local variable beforeit is written once on dev->mtu, as lockless readers couldcatch wrong temporary value.[1]skbuff: skb_over_panic: text:ffff80000b7a2f38 len:40 put:40 head:ffff000149dcf200 data:ffff000149dcf2b0 tail:0xd8 end:0xc0 dev:ip6gretap0------------[ cut here ]------------kernel BUG at net/core/skbuff.c:120Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMPModules linked in:CPU: 1 PID: 10241 Comm: kworker/1:1 Not tainted 6.0.0-rc7-syzkaller-18095-gbbed346d5a96 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/30/2022Workqueue: mld mld_ifc_workpstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : skb_panic+0x4c/0x50 net/core/skbuff.c:116lr : skb_panic+0x4c/0x50 net/core/skbuff.c:116sp : ffff800020dd3b60x29: ffff800020dd3b70 x28: 0000000000000000 x27: ffff00010df2a800x26: 00000000000000c0 x25: 00000000000000b0 x24: ffff000149dcf200x23: 00000000000000c0 x22: 00000000000000d8 x21: ffff80000b7a2f38x20: ffff00014c2f7800 x19: 0000000000000028 x18: 00000000000001a9x17: 0000000000000000 x16: ffff80000db49158 x15: ffff000113bf1a80x14: 0000000000000000 x13: 00000000ffffffff x12: ffff000113bf1a80x11: ff808000081c0d5c x10: 0000000000000000 x9 : 73f125dc5c63ba00x8 : 73f125dc5c63ba00 x7 : ffff800008161d1c x6 : 0000000000000000x5 : 0000000000000080 x4 : 0000000000000001 x3 : 0000000000000000x2 : ffff0001fefddcd0 x1 : 0000000100000000 x0 : 0000000000000089Call trace:skb_panic+0x4c/0x50 net/core/skbuff.c:116skb_over_panic net/core/skbuff.c:125 [inline]skb_put+0xd4/0xdc net/core/skbuff.c:2049ip6_mc_hdr net/ipv6/mcast.c:1714 [inline]mld_newpack+0x14c/0x270 net/ipv6/mcast.c:1765add_grhead net/ipv6/mcast.c:1851 [inline]add_grec+0xa20/0xae0 net/ipv6/mcast.c:1989mld_send_cr+0x438/0x5a8 net/ipv6/mcast.c:2115mld_ifc_work+0x38/0x290 net/ipv6/mcast.c:2653process_one_work+0x2d8/0x504 kernel/workqueue.c:2289worker_thread+0x340/0x610 kernel/workqueue.c:2436kthread+0x12c/0x158 kernel/kthread.c:376ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860Code: 91011400 aa0803e1 a90027ea 94373093 (d4210000)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl/mem: Fix shutdown orderIra reports that removing cxl_mock_mem causes a crash with the followingtrace: BUG: kernel NULL pointer dereference, address: 0000000000000044 [..] RIP: 0010:cxl_region_decode_reset+0x7f/0x180 [cxl_core] [..] Call Trace: cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x29/0x40 [cxl_core] devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1d2/0x210 bus_remove_device+0xd7/0x150 device_del+0x155/0x3e0 device_unregister+0x13/0x60 devm_release_action+0x4d/0x90 ? __pfx_unregister_port+0x10/0x10 [cxl_core] delete_endpoint+0x121/0x130 [cxl_core] devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1d2/0x210 bus_remove_device+0xd7/0x150 device_del+0x155/0x3e0 ? lock_release+0x142/0x290 cdev_device_del+0x15/0x50 cxl_memdev_unregister+0x54/0x70 [cxl_core]This crash is due to the clearing out the cxl_memdev's driver context(@cxlds) before the subsystem is done with it. This is ultimately due tothe region(s), that this memdev is a member, being torn down and expectingto be able to de-reference @cxlds, like here:static int cxl_region_decode_reset(struct cxl_region *cxlr, int count)... if (cxlds->rcd) goto endpoint_reset;...Fix it by keeping the driver context valid until memdev-deviceunregistration, and subsequently the entire stack of relateddependencies, unwinds.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: allow ext4_get_group_info() to failPreviously, ext4_get_group_info() would treat an invalid group numberas BUG(), since in theory it should never happen. However, if amalicious attaker (or fuzzer) modifies the superblock via the blockdevice while it is the file system is mounted, it is possible fors_first_data_block to get set to a very large number. In that case,when calculating the block group of some block number (such as thestarting block of a preallocation region), could result in anunderflow and very large block group number. Then the BUG_ON check inext4_get_group_info() would fire, resutling in a denial of serviceattack that can be triggered by root or someone with write access tothe block device.For a quality of implementation perspective, it's best that even ifthe system administrator does something that they shouldn't, that itwill not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()will call ext4_error and return NULL. We also add fallback code inall of the callers of ext4_get_group_info() that it might NULL.Also, since ext4_get_group_info() was already borderline to be aninline function, un-inline it. The results in a next reduction of thecompiled text size of ext4 by roughly 2k.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: check for station first in client probeWhen probing a client, first check if we have it, and thencheck for the channel context, otherwise you can triggerthe warning there easily by probing when the AP isn't evenstarted yet. Since a client existing means the AP is alsooperating, we can then keep the warning.Also simplify the moved code a bit.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-af: Add validation before accessing cgx and lmacwith the addition of new MAC blocks like CN10K RPM and CN10KBRPM_USX, LMACs are noncontiguous and CGX blocks are alsononcontiguous. But during RVU driver initialization, the driveris assuming they are contiguous and trying to accesscgx or lmac with their id which is resulting in kernel panic.This patch fixes the issue by adding proper checks.[ 23.219150] pc : cgx_lmac_read+0x38/0x70[ 23.219154] lr : rvu_program_channels+0x3f0/0x498[ 23.223852] sp : ffff000100d6fc80[ 23.227158] x29: ffff000100d6fc80 x28: ffff00010009f880 x27:000000000000005a[ 23.234288] x26: ffff000102586768 x25: 0000000000002500 x24:fffffffffff0f000
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Avoid stack overflow due to __rcu_irq_enter_check_tick() being kprobe-edRegistering a kprobe on __rcu_irq_enter_check_tick() can cause kernelstack overflow as shown below. This issue can be reproduced by enablingCONFIG_NO_HZ_FULL and booting the kernel with argument "nohz_full=",and then giving the following commands at the shell prompt: # cd /sys/kernel/tracing/ # echo 'p:mp1 __rcu_irq_enter_check_tick' >> kprobe_events # echo 1 > events/kprobes/enableThis commit therefore adds __rcu_irq_enter_check_tick() to the kprobesblacklist using NOKPROBE_SYMBOL().Insufficient stack space to handle exception!ESR: 0x00000000f2000004 -- BRK (AArch64)FAR: 0x0000ffffccf3e510Task stack: [0xffff80000ad30000..0xffff80000ad38000]IRQ stack: [0xffff800008050000..0xffff800008058000]Overflow stack: [0xffff089c36f9f310..0xffff089c36fa0310]CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19Hardware name: linux,dummy-virt (DT)pstate: 400003c5 (nZcv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __rcu_irq_enter_check_tick+0x0/0x1b8lr : ct_nmi_enter+0x11c/0x138sp : ffff80000ad30080x29: ffff80000ad30080 x28: ffff089c82e20000 x27: 0000000000000000x26: 0000000000000000 x25: ffff089c02a8d100 x24: 0000000000000000x23: 00000000400003c5 x22: 0000ffffccf3e510 x21: ffff089c36fae148x20: ffff80000ad30120 x19: ffffa8da8fcce148 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: ffffa8da8e44ea6cx14: ffffa8da8e44e968 x13: ffffa8da8e03136c x12: 1fffe113804d6809x11: ffff6113804d6809 x10: 0000000000000a60 x9 : dfff800000000000x8 : ffff089c026b404f x7 : 00009eec7fb297f7 x6 : 0000000000000001x5 : ffff80000ad30120 x4 : dfff800000000000 x3 : ffffa8da8e3016f4x2 : 0000000000000003 x1 : 0000000000000000 x0 : 0000000000000000Kernel panic - not syncing: kernel stack overflowCPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19Hardware name: linux,dummy-virt (DT)Call trace: dump_backtrace+0xf8/0x108 show_stack+0x20/0x30 dump_stack_lvl+0x68/0x84 dump_stack+0x1c/0x38 panic+0x214/0x404 add_taint+0x0/0xf8 panic_bad_stack+0x144/0x160 handle_bad_stack+0x38/0x58 __bad_stack+0x78/0x7c __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 [...] el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 el1_interrupt+0x28/0x60 el1h_64_irq_handler+0x18/0x28 el1h_64_irq+0x64/0x68 __ftrace_set_clr_event_nolock+0x98/0x198 __ftrace_set_clr_event+0x58/0x80 system_enable_write+0x144/0x178 vfs_write+0x174/0x738 ksys_write+0xd0/0x188 __arm64_sys_write+0x4c/0x60 invoke_syscall+0x64/0x180 el0_svc_common.constprop.0+0x84/0x160 do_el0_svc+0x48/0xe8 el0_svc+0x34/0xd0 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x190/0x194SMP: stopping secondary CPUsKernel Offset: 0x28da86000000 from 0xffff800008000000PHYS_OFFSET: 0xfffff76600000000CPU features: 0x00000,01a00100,0000421bMemory Limit: none
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv4: fix one memleak in __inet_del_ifa()I got the below warning when do fuzzing test:unregister_netdevice: waiting for bond0 to become free. Usage count = 2It can be repoduced via:ip link add bond0 type bondsysctl -w net.ipv4.conf.bond0.promote_secondaries=1ip addr add 4.117.174.103/0 scope 0x40 dev bond0ip addr add 192.168.100.111/255.255.255.254 scope 0 dev bond0ip addr add 0.0.0.4/0 scope 0x40 secondary dev bond0ip addr del 4.117.174.103/0 scope 0x40 dev bond0ip link delete bond0 type bondIn this reproduction test case, an incorrect 'last_prim' is found in__inet_del_ifa(), as a result, the secondary address(0.0.0.4/0 scope 0x40)is lost. The memory of the secondary address is leaked and the reference ofin_device and net_device is leaked.Fix this problem:Look for 'last_prim' starting at location of the deleted IP and insertingthe promoted IP into the location of 'last_prim'.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: Vim is an open source, command line text editor. Patch v9.1.0038 optimized how the cursor position is calculated and removed a loop, that verified that the cursor position always points inside a line and does not become invalid by pointing beyond the end ofa line. Back then we assumed this loop is unnecessary. However, this change made it possible that the cursor position stays invalid and points beyond the end of a line, which would eventually cause a heap-buffer-overflow when trying to access the line pointer atthe specified cursor position. It's not quite clear yet, what can lead to this situation that the cursor points to an invalid position. That's why patch v9.1.0707 does not include a test case. The only observed impact has been a program crash. This issue has been addressed in with the patch v9.1.0707. All users are advised to upgrade.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- vim > 0-0 (version in image is 9.2.0280-150500.20.46.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Prevent tailcall infinite loop caused by freplaceThere is a potential infinite loop issue that can occur when using acombination of tail calls and freplace.In an upcoming selftest, the attach target for entry_freplace oftailcall_freplace.c is subprog_tc of tc_bpf2bpf.c, while the tail call inentry_freplace leads to entry_tc. This results in an infinite loop:entry_tc -> subprog_tc -> entry_freplace --tailcall-> entry_tc.The problem arises because the tail_call_cnt in entry_freplace resets tozero each time entry_freplace is executed, causing the tail call mechanismto never terminate, eventually leading to a kernel panic.To fix this issue, the solution is twofold:1. Prevent updating a program extended by an freplace program to a prog_array map.2. Prevent extending a program that is already part of a prog_array map with an freplace program.This ensures that:* If a program or its subprogram has been extended by an freplace program, it can no longer be updated to a prog_array map.* If a program has been added to a prog_array map, neither it nor its subprograms can be extended by an freplace program.Moreover, an extension program should not be tailcalled. As such, return-EINVAL if the program has a type of BPF_PROG_TYPE_EXT when adding it to aprog_array map.Additionally, fix a minor code style issue by replacing eight spaces with atab for proper formatting.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-rdma: unquiesce admin_q before destroy itKernel will hang on destroy admin_q while we create ctrl failed, suchas following calltrace:PID: 23644 TASK: ff2d52b40f439fc0 CPU: 2 COMMAND: "nvme" #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15 #1 [ff61d23de260fc08] schedule at ffffffff8323c014 #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1 #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006 #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl at ffffffffc1268ced #7 [ff61d23de260fd28] nvme_rdma_create_ctrl at ffffffffc126919b #8 [ff61d23de260fd68] nvmf_dev_write at ffffffffc024f362 #9 [ff61d23de260fe38] vfs_write at ffffffff827d5f25 RIP: 00007fda7891d574 RSP: 00007ffe2ef06958 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 000055e8122a4d90 RCX: 00007fda7891d574 RDX: 000000000000012b RSI: 000055e8122a4d90 RDI: 0000000000000004 RBP: 00007ffe2ef079c0 R8: 000000000000012b R9: 000055e8122a4d90 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000004 R13: 000055e8122923c0 R14: 000000000000012b R15: 00007fda78a54500 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002bThis due to we have quiesced admi_q before cancel requests, but forgotto unquiesce before destroy it, as a result we fail to drain thepending requests, and hang on blk_mq_freeze_queue_wait() forever. Heretry to reuse nvme_rdma_teardown_admin_queue() to fix this issue andsimplify the code.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: devmap: provide rxq after redirectrxq contains a pointer to the device from wherethe redirect happened. Currently, the BPF programthat was executed after a redirect via BPF_MAP_TYPE_DEVMAP*does not have it set.This is particularly bad since accessing ingress_ifindex, e.g.SEC("xdp")int prog(struct xdp_md *pkt){ return bpf_redirect_map(&dev_redirect_map, 0, 0);}SEC("xdp/devmap")int prog_after_redirect(struct xdp_md *pkt){ bpf_printk("ifindex %i", pkt->ingress_ifindex); return XDP_PASS;}depends on access to rxq, so a NULL pointer gets dereferenced:<1>[ 574.475170] BUG: kernel NULL pointer dereference, address: 0000000000000000<1>[ 574.475188] #PF: supervisor read access in kernel mode<1>[ 574.475194] #PF: error_code(0x0000) - not-present page<6>[ 574.475199] PGD 0 P4D 0<4>[ 574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<4>[ 574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 Not tainted 6.11.0-rc5-reduced-00859-g780801200300 #23<4>[ 574.475226] Hardware name: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 03/14/2023<4>[ 574.475231] Workqueue: mld mld_ifc_work<4>[ 574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c<4>[ 574.475257] Code: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 <48> 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b<4>[ 574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206<4>[ 574.475269] RAX: ffffa62440280cd8 RBX: 0000000000000001 RCX: 0000000000000000<4>[ 574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0<4>[ 574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001<4>[ 574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000<4>[ 574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000<4>[ 574.475289] FS: 0000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000<4>[ 574.475294] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<4>[ 574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0<4>[ 574.475303] PKRU: 55555554<4>[ 574.475306] Call Trace:<4>[ 574.475313] <4>[ 574.475318] ? __die+0x23/0x70<4>[ 574.475329] ? page_fault_oops+0x180/0x4c0<4>[ 574.475339] ? skb_pp_cow_data+0x34c/0x490<4>[ 574.475346] ? kmem_cache_free+0x257/0x280<4>[ 574.475357] ? exc_page_fault+0x67/0x150<4>[ 574.475368] ? asm_exc_page_fault+0x26/0x30<4>[ 574.475381] ? bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c<4>[ 574.475386] bq_xmit_all+0x158/0x420<4>[ 574.475397] __dev_flush+0x30/0x90<4>[ 574.475407] veth_poll+0x216/0x250 [veth]<4>[ 574.475421] __napi_poll+0x28/0x1c0<4>[ 574.475430] net_rx_action+0x32d/0x3a0<4>[ 574.475441] handle_softirqs+0xcb/0x2c0<4>[ 574.475451] do_softirq+0x40/0x60<4>[ 574.475458] <4>[ 574.475461] <4>[ 574.475464] __local_bh_enable_ip+0x66/0x70<4>[ 574.475471] __dev_queue_xmit+0x268/0xe40<4>[ 574.475480] ? selinux_ip_postroute+0x213/0x420<4>[ 574.475491] ? alloc_skb_with_frags+0x4a/0x1d0<4>[ 574.475502] ip6_finish_output2+0x2be/0x640<4>[ 574.475512] ? nf_hook_slow+0x42/0xf0<4>[ 574.475521] ip6_finish_output+0x194/0x300<4>[ 574.475529] ? __pfx_ip6_finish_output+0x10/0x10<4>[ 574.475538] mld_sendpack+0x17c/0x240<4>[ 574.475548] mld_ifc_work+0x192/0x410<4>[ 574.475557] process_one_work+0x15d/0x380<4>[ 574.475566] worker_thread+0x29d/0x3a0<4>[ 574.475573] ? __pfx_worker_thread+0x10/0x10<4>[ 574.475580] ? __pfx_worker_thread+0x10/0x10<4>[ 574.475587] kthread+0xcd/0x100<4>[ 574.475597] ? __pfx_kthread+0x10/0x10<4>[ 574.475606] ret_from_fork+0x31/0x50<4>[ 574.475615] ? __pfx_kthread+0x10/0x10<4>[ 574.475623] ret_from_fork_asm+0x1a/0x---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: ts2020: fix null-ptr-deref in ts2020_probe()KASAN reported a null-ptr-deref issue when executing the followingcommand: # echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020] RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809 RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010 RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6 R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790 R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001 FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ts2020_probe+0xad/0xe10 [ts2020] i2c_device_probe+0x421/0xb40 really_probe+0x266/0x850 ...The cause of the problem is that when using sysfs to dynamically registeran i2c device, there is no platform data, but the probe process of ts2020needs to use platform data, resulting in a null pointer being accessed.Solve this problem by adding checks to platform data.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Create all dump files during debugfs initializationFor the current debugfs of hisi_sas, after user triggers dump, thedriver allocate memory space to save the register information and createdebugfs files to display the saved information. In this process, thedebugfs files created after each dump.Therefore, when the dump is triggered while the driver is unbind, thefollowing hang occurs:[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0[67840.862947] Mem abort info:[67840.865855] ESR = 0x0000000096000004[67840.869713] EC = 0x25: DABT (current EL), IL = 32 bits[67840.875125] SET = 0, FnV = 0[67840.878291] EA = 0, S1PTW = 0[67840.881545] FSC = 0x04: level 0 translation fault[67840.886528] Data abort info:[67840.889524] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[67840.895117] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[67840.900284] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000[67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000[67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[67841.003628] pc : down_write+0x30/0x98[67841.007546] lr : start_creating.part.0+0x60/0x198[67841.012495] sp : ffff8000b979ba20[67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40[67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8[67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18[67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020[67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff[67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18[67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18[67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9[67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001[67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0[67841.089759] Call trace:[67841.092456] down_write+0x30/0x98[67841.096017] start_creating.part.0+0x60/0x198[67841.100613] debugfs_create_dir+0x48/0x1f8[67841.104950] debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw][67841.111447] debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw][67841.118111] debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw][67841.125115] full_proxy_write+0x68/0xc8[67841.129175] vfs_write+0xd8/0x3f0[67841.132708] ksys_write+0x70/0x108[67841.136317] __arm64_sys_write+0x24/0x38[67841.140440] invoke_syscall+0x50/0x128[67841.144385] el0_svc_common.constprop.0+0xc8/0xf0[67841.149273] do_el0_svc+0x24/0x38[67841.152773] el0_svc+0x38/0xd8[67841.156009] el0t_64_sync_handler+0xc0/0xc8[67841.160361] el0t_64_sync+0x1a4/0x1a8[67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05)[67841.170443] ---[ end trace 0000000000000000 ]---To fix this issue, create all directories and files during debugfsinitialization. In this way, the driver only needs to allocate memoryspace to save information each time the user triggers dumping.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: avoid NULL pointer error during sdio removeWhen running 'rmmod ath10k', ath10k_sdio_remove() will free sdioworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ONis set to yes, kernel panic will happen:Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2cThis is because during 'rmmod ath10k', ath10k_sdio_remove() will callath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()will finally be called in ath10k_core_destroy(). This function will freestruct cfg80211_registered_device *rdev and all its members, includingwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdioworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.After device release, destroy_workqueue() will use NULL pointer then thekernel panic happen.Call trace:ath10k_sdio_remove ->ath10k_core_unregister ...... ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free ...... ->wiphy_dev_release ->destroy_workqueueNeed to call destroy_workqueue() before ath10k_core_destroy(), freethe work queue buffer first and then free pointer of work queue byath10k_core_destroy(). This order matches the error path order inath10k_sdio_probe().No work will be queued on sdio workqueue between it is destroyed andath10k_core_destroy() is called. Based on the call_stack above, thereason is:Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() andath10k_sdio_irq_disable() will queue work on sdio workqueue.Sleep timer will be deleted before ath10k_core_destroy() inath10k_hif_power_down().ath10k_sdio_irq_disable() only be called in ath10k_hif_stop().ath10k_core_unregister() will call ath10k_hif_power_down() to stop hifbus, so ath10k_sdio_hif_tx_sg() won't be called anymore.Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: hugetlb: independent PMD page table shared countThe folio refcount may be increased unexpectly through try_get_folio() bycaller such as split_huge_pages. In huge_pmd_unshare(), we use refcountto check whether a pmd page table is shared. The check is incorrect ifthe refcount is increased by the above caller, and this can cause the pagetable leaked: BUG: Bad page state in process sh pfn:109324 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324 flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff) page_type: f2(table) raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000 raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000 page dumped because: nonzero mapcount ... CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G B 6.13.0-rc2master+ #7 Tainted: [B]=BAD_PAGE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 dump_stack+0x18/0x28 bad_page+0x8c/0x130 free_page_is_bad_report+0xa4/0xb0 free_unref_page+0x3cc/0x620 __folio_put+0xf4/0x158 split_huge_pages_all+0x1e0/0x3e8 split_huge_pages_write+0x25c/0x2d8 full_proxy_write+0x64/0xd8 vfs_write+0xcc/0x280 ksys_write+0x70/0x110 __arm64_sys_write+0x24/0x38 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x34/0x128 el0t_64_sync_handler+0xc8/0xd0 el0t_64_sync+0x190/0x198The issue may be triggered by damon, offline_page, page_idle, etc, whichwill increase the refcount of page table.1. The page table itself will be discarded after reporting the "nonzero mapcount".2. The HugeTLB page mapped by the page table miss freeing since we treat the page table as shared and a shared page table will not be unmapped.Fix it by introducing independent PMD page table shared count. Asdescribed by comment, pt_index/pt_mm/pt_frag_refcount are used for s390gmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscvpmds, so we can reuse the field as pt_share_count.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla1280: Fix kernel oops when debug level > 2A null dereference or oops exception will eventually occur when qla1280.cdriver is compiled with DEBUG_QLA1280 enabled and ql_debug_level > 2. Ithink its clear from the code that the intention here is sg_dma_len(s) notlength of sg_next(s) when printing the debug info.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: decrease cached dst counters in dst_releaseUpstream fix ac888d58869b ("net: do not delay dst_entries_add() indst_release()") moved decrementing the dst count from dst_destroy todst_release to avoid accessing already freed data in case of netnsdismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnelsare used, this fix is incomplete as the same issue will be seen forcached dsts: Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30Fix this by invalidating the cache, and thus decrementing cached dstcounters, in dst_release too.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID as a hostname component. For example, when the NO_PROXY environment variable is set to "*.example.com", a request to "[::1%25.example.com]:80` will incorrectly match and not be proxied.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- containerd > 0-0 (version in image is 1.7.29-150000.132.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: add sanity check for agwidth in dbMountThe width in dmapctl of the AG is zero, it trigger a divide error whencalculating the control page level in dbAllocAG.To avoid this issue, add a check for agwidth in dbAllocAG.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/sclp: Add check for get_zeroed_page()Add check for the return value of get_zeroed_page() insclp_console_init() to prevent null pointer dereference.Furthermore, to solve the memory leak caused by the loopallocation, add a free helper to do the free job.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix oob write in trace_seq_to_buffer()syzbot reported this bug:==================================================================BUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]BUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106 trace_seq_to_buffer kernel/trace/trace.c:1830 [inline] tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822 ....==================================================================It has been reported that trace_seq_to_buffer() tries to copy more datathan PAGE_SIZE to buf. Therefore, to prevent this, we should use thesmaller of trace_seq_used(&iter->seq) and PAGE_SIZE as an argument.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihidThere is a string parsing logic error which can lead to an overflow of hidor uid buffers. Comparing ACPIID_LEN against a total string length doesn'ttake into account the lengths of individual hid and uid buffers so thecheck is insufficient in some cases. For example if the length of hidstring is 4 and the length of the uid string is 260, the length of strwill be equal to ACPIID_LEN + 1 but uid string will overflow uid bufferwhich size is 256.The same applies to the hid string with length 13 and uid string withlength 250.Check the length of hid and uid strings separately to preventbuffer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: displayport: Fix NULL pointer accessThis patch ensures that the UCSI driver waits for all pending tasks in theucsi_displayport_work workqueue to finish executing before proceeding withthe partner removal.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: correct the order of prelim_ref arguments in btrfs__prelim_refbtrfs_prelim_ref() calls the old and new reference variables in theincorrect order. This causes a NULL pointer dereference because oldrefis passed as NULL to trace_btrfs_prelim_ref_insert().Note, trace_btrfs_prelim_ref_insert() is being called with newref asoldref (and oldref as NULL) on purpose in order to print outthe values of newref.To reproduce:echo 1 > /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enablePerform some writeback operations.Backtrace:BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary) 7ca2cef72d5e9c600f0c7718adb6462de8149622 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014 RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130 Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 <49> 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88 RSP: 0018:ffffce44820077a0 EFLAGS: 00010286 RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010 R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000 R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540 FS: 00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: prelim_ref_insert+0x1c1/0x270 find_parent_nodes+0x12a6/0x1ee0 ? __entry_text_end+0x101f06/0x101f09 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 btrfs_is_data_extent_shared+0x167/0x640 ? fiemap_process_hole+0xd0/0x2c0 extent_fiemap+0xa5c/0xbc0 ? __entry_text_end+0x101f05/0x101f09 btrfs_fiemap+0x7e/0xd0 do_vfs_ioctl+0x425/0x9d0 __x64_sys_ioctl+0x75/0xc0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: k3-udma-glue: Drop skip_fdq argument from k3_udma_glue_reset_rx_chnThe user of k3_udma_glue_reset_rx_chn() e.g. ti_am65_cpsw_nuss canrun on multiple platforms having different DMA architectures.On some platforms there can be one FDQ for all flows in the RX channelwhile for others there is a separate FDQ for each flow in the RX channel.So far we have been relying on the skip_fdq argument ofk3_udma_glue_reset_rx_chn().Instead of relying on the user to provide this information, infer itbased on DMA architecture during k3_udma_glue_request_rx_chn() and save itin an internal flag 'single_fdq'. Use that flag atk3_udma_glue_reset_rx_chn() to deicide if the FDQ needsto be cleared for every flow or just for flow 0.Fixes the below issue on ti_am65_cpsw_nuss driver on AM62-SK.> ip link set eth1 down> ip link set eth0 down> ethtool -L eth0 rx 8> ip link set eth0 up> modprobe -r ti_am65_cpsw_nuss[ 103.045726] ------------[ cut here ]------------[ 103.050505] k3_knav_desc_pool size 512000 != avail 64000[ 103.050703] WARNING: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool][ 103.068810] Modules linked in: ti_am65_cpsw_nuss(-) k3_cppi_desc_pool snd_soc_hdmi_codec crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils display_connector rtc_ti_k3 k3_j72xx_bandgap tidss drm_client_lib snd_soc_davinci_mcasp drm_dma_helper tps6598x phylink snd_soc_ti_udma rti_wdt drm_display_helper snd_soc_tlv320aic3x_i2c typec at24 phy_gmii_sel snd_soc_ti_edma snd_soc_tlv320aic3x sii902x snd_soc_ti_sdma sa2ul omap_mailbox drm_kms_helper authenc cfg80211 rfkill fuse drm drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [last unloaded: k3_cppi_desc_pool][ 103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011[ 103.119968] Hardware name: Texas Instruments AM625 SK (DT)[ 103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 103.119983] pc : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool][ 103.148007] lr : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool][ 103.154709] sp : ffff8000826ebbc0[ 103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000[ 103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0[ 103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88[ 103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000[ 103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde[ 103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000[ 103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20[ 103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100[ 103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000[ 103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000[ 103.229274] Call trace:[ 103.231714] k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] (P)[ 103.238408] am65_cpsw_nuss_free_rx_chns+0x28/0x4c [ti_am65_cpsw_nuss][ 103.244942] devm_action_release+0x14/0x20[ 103.249040] release_nodes+0x3c/0x68[ 103.252610] devres_release_all+0x8c/0xdc[ 103.256614] device_unbind_cleanup+0x18/0x60[ 103.260876] device_release_driver_internal+0xf8/0x178[ 103.266004] driver_detach+0x50/0x9c[ 103.269571] bus_remove_driver+0x6c/0xbc[ 103.273485] driver_unregister+0x30/0x60[ 103.277401] platform_driver_unregister+0x14/0x20[ 103.282096] am65_cpsw_nuss_driver_exit+0x18/0xff4 [ti_am65_cpsw_nuss][ 103.288620] __arm64_sys_delete_module+0x17c/0x25c[ 103.293404] invoke_syscall+0x44/0x100[ 103.297149] el0_svc_common.constprop.0+0xc0/0xe0[ 103.301845] do_el0_svc+0x1c/0x28[ 103.305155] el0_svc+0x28/0x98---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm: fix unconditional IO throttle caused by REQ_PREFLUSHWhen a bio with REQ_PREFLUSH is submitted to dm, __send_empty_flush()generates a flush_bio with REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC,which causes the flush_bio to be throttled by wbt_wait().An example from v5.4, similar problem also exists in upstream: crash> bt 2091206 PID: 2091206 TASK: ffff2050df92a300 CPU: 109 COMMAND: "kworker/u260:0" #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8 #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4 #2 [ffff800084a2f880] schedule at ffff800040bfa4b4 #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4 #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0 #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254 #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38 #8 [ffff800084a2fa60] generic_make_request at ffff800040570138 #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4 #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs] #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs] #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs] #13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs] #14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs] #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs] #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08 #17 [ffff800084a2fe00] worker_thread at ffff8000401121cc #18 [ffff800084a2fe70] kthread at ffff800040118de4After commit 2def2845cc33 ("xfs: don't allow log IO to be throttled"),the metadata submitted by xlog_write_iclog() should not be throttled.But due to the existence of the dm layer, throttling flush_bio indirectlycauses the metadata bio to be throttled.Fix this by conditionally adding REQ_IDLE to flush_bio.bi_opf, which makeswbt_should_throttle() return false to avoid wbt_wait().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/iopl: Cure TIF_IO_BITMAP inconsistenciesio_bitmap_exit() is invoked from exit_thread() when a task exists orwhen a fork fails. In the latter case the exit_thread() cleans upresources which were allocated during fork().io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends upin tss_update_io_bitmap(). tss_update_io_bitmap() operates on thecurrent task. If current has TIF_IO_BITMAP set, but no bitmap installed,tss_update_io_bitmap() crashes with a NULL pointer dereference.There are two issues, which lead to that problem: 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork(). 2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated. This happens when a kernel thread is created in the context of a user space thread, which has TIF_IO_BITMAP set as the thread flags are copied and the IO bitmap pointer is cleared. Other than in the failed fork() case this has no impact because kernel threads including IO workers never return to user space and therefore never invoke tss_update_io_bitmap().Cure this by adding the missing cleanups and checks: 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task. 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share().For paranoia sake, add a warning into tss_update_io_bitmap() to catchthe case, when that code is invoked with inconsistent state.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: Fix potential null-ptr-deref in mlb_usio_probe()devm_ioremap() can return NULL on error. Currently, mlb_usio_probe()does not check for this case, which could result in a NULL pointerdereference.Add NULL check after devm_ioremap() to prevent this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: core: Clear table_sz when rproc_shutdownThere is case as below could trigger kernel dump:Use U-Boot to start remote processor(rproc) with resource tablepublished to a fixed address by rproc. After Kernel boots up,stop the rproc, load a new firmware which doesn't have resource table,and start rproc.When starting rproc with a firmware not have resource table,`memcpy(loaded_table, rproc->cached_table, rproc->table_sz)` willtrigger dump, because rproc->cache_table is set to NULL during the laststop operation, but rproc->table_sz is still valid.This issue is found on i.MX8MP and i.MX9.Dump as below:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation faultData abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000[0000000000000000] pgd=0000000000000000, p4d=0000000000000000Internal error: Oops: 0000000096000004 [#1] PREEMPT SMPModules linked in:CPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38Hardware name: NXP i.MX8MPlus EVK board (DT)pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __pi_memcpy_generic+0x110/0x22clr : rproc_start+0x88/0x1e0Call trace: __pi_memcpy_generic+0x110/0x22c (P) rproc_boot+0x198/0x57c state_store+0x40/0x104 dev_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x120/0x1cc vfs_write+0x240/0x378 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xcc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19cClear rproc->table_sz to address the issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_varIf fb_add_videomode() in do_register_framebuffer() fails to allocatememory for fb_videomode, it will later lead to a null-ptr dereference infb_videomode_to_var(), as the fb_info is registered while not having themode in modelist that is expected to be there, i.e. the one that isdescribed in fb_info->var.================================================================general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1================================================================Even though fbcon_init() checks beforehand if fb_match_mode() invar_to_display() fails, it can not prevent the panic because fbcon_init()does not return error code. Considering this and the comment in the codeabout fb_match_mode() returning NULL - "This should not happen" - it isbetter to prevent registering the fb_info if its mode was not setsuccessfully. Also move fb_add_videomode() closer to the beginning ofdo_register_framebuffer() to avoid having to do the cleanup on fail.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: cxusb: no longer judge rbuf when the write failssyzbot reported a uninit-value in cxusb_i2c_xfer. [1]Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw()succeeds and rlen is greater than 0, the read operation of usb_bulk_msg()will be executed to read rlen bytes of data from the dvb device into therbuf.In this case, although rlen is 1, the write operation failed which resultedin the dvb read operation not being executed, and ultimately variable i wasnot initialized.[1]BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1 i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315 i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343 i2c_master_send include/linux/i2c.h:109 [inline] i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183 do_loop_readv_writev fs/read_write.c:848 [inline] vfs_writev+0x963/0x14e0 fs/read_write.c:1057 do_writev+0x247/0x5c0 fs/read_write.c:1101 __do_sys_writev fs/read_write.c:1169 [inline] __se_sys_writev fs/read_write.c:1166 [inline] __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166 x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000,cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It'sthen passed to fb_cvt_hperiod(), where it's used as a divider -- divisionby 0 will result in kernel oops. Add a sanity check for cvt.f_refresh toavoid such overflow...Found by Linux Verification Center (linuxtesting.org) with the Svace staticanalysis tool.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: Log an error when close_all_cached_dirs failsUnder low-memory conditions, close_all_cached_dirs() can't move thedentries to a separate list to dput() them once the locks are dropped.This will result in a "Dentry still in use" error, so add an errormessage that makes it clear this is what happened:[ 495.281119] CIFS: VFS: \\otters.example.com\share Out of memory while dropping dentries[ 495.281595] ------------[ cut here ]------------[ 495.281887] BUG: Dentry ffff888115531138{i=78,n=/} still in use (2) [unmount of cifs cifs][ 495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0Also, bail out of looping through all tcons as soon as a singleallocation fails, since we're already in trouble, and kmalloc() attemptsfor subseqeuent tcons are likely to fail just like the first one did.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:software node: Correct a OOB check in software_node_get_reference_args()software_node_get_reference_args() wants to get @index-th element, sothe property value requires at least '(index + 1) * sizeof(*ref)' bytesbut that can not be guaranteed by current OOB check, and may cause OOBfor malformed property.Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: fix acpi operand cache leak in dswstate.cACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732I found an ACPI cache leak in ACPI early termination and boot continuing case.When early termination occurs due to malicious ACPI table, Linux kernelterminates ACPI function and continues to boot process. While kernel terminatesACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.Boot log of ACPI operand cache leak is as follows:>[ 0.585957] ACPI: Added _OSI(Module Device)>[ 0.587218] ACPI: Added _OSI(Processor Device)>[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)>[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device)>[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155)>[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88)>[ 0.597858] ACPI: Unable to start the ACPI Interpreter>[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)>[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects>[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26>[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006>[ 0.609177] Call Trace:>[ 0.610063] ? dump_stack+0x5c/0x81>[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0>[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27>[ 0.613906] ? acpi_os_delete_cache+0xa/0x10>[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b>[ 0.619293] ? acpi_terminate+0xa/0x14>[ 0.620394] ? acpi_init+0x2af/0x34f>[ 0.621616] ? __class_create+0x4c/0x80>[ 0.623412] ? video_setup+0x7f/0x7f>[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27>[ 0.625861] ? do_one_initcall+0x4e/0x1a0>[ 0.627513] ? kernel_init_freeable+0x19e/0x21f>[ 0.628972] ? rest_init+0x80/0x80>[ 0.630043] ? kernel_init+0xa/0x100>[ 0.631084] ? ret_from_fork+0x25/0x30>[ 0.633343] vgaarb: loaded>[ 0.635036] EDAC MC: Ver: 3.0.0>[ 0.638601] PCI: Probing PCI hardware>[ 0.639833] PCI host bridge to bus 0000:00>[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]> ... Continue to boot and log is omitted ...I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()function uses walk_state->operand_index for start position of the top, butacpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.Therefore, this causes acpi operand memory leak.This cache leak causes a security threat because an old kernel (<= 4.9) showsmemory locations of kernel functions in stack dump. Some malicious userscould use this information to neutralize kernel ASLR.I made a patch to fix ACPI operand cache leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfs: Clean up /proc/net/rpc/nfs when nfs_fs_proc_net_init() fails.syzbot reported a warning below [1] following a fault injection innfs_fs_proc_net_init(). [0]When nfs_fs_proc_net_init() fails, /proc/net/rpc/nfs is not removed.Later, rpc_proc_exit() tries to remove /proc/net/rpc, and the warningis logged as the directory is not empty.Let's handle the error of nfs_fs_proc_net_init() properly.[0]:FAULT_INJECTION: forcing a failure.name failslab, interval 1, probability 0, space 0, times 0CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Call Trace: dump_stack_lvl (lib/dump_stack.c:123) should_fail_ex (lib/fault-inject.c:73 lib/fault-inject.c:174) should_failslab (mm/failslab.c:46) kmem_cache_alloc_noprof (mm/slub.c:4178 mm/slub.c:4204) __proc_create (fs/proc/generic.c:427) proc_create_reg (fs/proc/generic.c:554) proc_create_net_data (fs/proc/proc_net.c:120) nfs_fs_proc_net_init (fs/nfs/client.c:1409) nfs_net_init (fs/nfs/inode.c:2600) ops_init (net/core/net_namespace.c:138) setup_net (net/core/net_namespace.c:443) copy_net_ns (net/core/net_namespace.c:576) create_new_namespaces (kernel/nsproxy.c:110) unshare_nsproxy_namespaces (kernel/nsproxy.c:218 (discriminator 4)) ksys_unshare (kernel/fork.c:3123) __x64_sys_unshare (kernel/fork.c:3190) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) [1]:remove_proc_entry: removing non-empty directory 'net/rpc', leaking at least 'nfs' WARNING: CPU: 1 PID: 6120 at fs/proc/generic.c:727 remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727Modules linked in:CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 RIP: 0010:remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727Code: 3c 02 00 0f 85 85 00 00 00 48 8b 93 d8 00 00 00 4d 89 f0 4c 89 e9 48 c7 c6 40 ba a2 8b 48 c7 c7 60 b9 a2 8b e8 33 81 1d ff 90 <0f> 0b 90 90 e9 5f fe ff ff e8 04 69 5e ff 90 48 b8 00 00 00 00 00RSP: 0018:ffffc90003637b08 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffff88805f534140 RCX: ffffffff817a92c8RDX: ffff88807da99e00 RSI: ffffffff817a92d5 RDI: 0000000000000001RBP: ffff888033431ac0 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000001 R12: ffff888033431a00R13: ffff888033431ae4 R14: ffff888033184724 R15: dffffc0000000000FS: 0000555580328500(0000) GS:ffff888124a62000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f71733743e0 CR3: 000000007f618000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: sunrpc_exit_net+0x46/0x90 net/sunrpc/sunrpc_syms.c:76 ops_exit_list net/core/net_namespace.c:200 [inline] ops_undo_list+0x2eb/0xab0 net/core/net_namespace.c:253 setup_net+0x2e1/0x510 net/core/net_namespace.c:457 copy_net_ns+0x2a6/0x5f0 net/core/net_namespace.c:574 create_new_namespaces+0x3ea/0xa90 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:218 ksys_unshare+0x45b/0xa40 kernel/fork.c:3121 __do_sys_unshare kernel/fork.c:3192 [inline] __se_sys_unshare kernel/fork.c:3190 [inline] __x64_sys_unshare+0x31/0x40 kernel/fork.c:3190 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x490 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fa1a6b8e929Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Reject narrower access to pointer ctx fieldsThe following BPF program, simplified from a syzkaller repro, causes akernel warning: r0 = *(u8 *)(r1 + 169); exit;With pointer field sk being at offset 168 in __sk_buff. This access isdetected as a narrower read in bpf_skb_is_valid_access because itdoesn't match offsetof(struct __sk_buff, sk). It is therefore allowedand later proceeds to bpf_convert_ctx_access. Note that for the"is_narrower_load" case in the convert_ctx_accesses(), the insn->offis aligned, so the cnt may not be 0 because it matches theoffsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However,the target_size stays 0 and the verifier errors with a kernel warning: verifier bug: error during ctx access conversion(1)This patch fixes that to return a proper "invalid bpf_context accessoff=X size=Y" error on the load instruction.The same issue affects multiple other fields in context structures thatallow narrow access. Some other non-affected fields (for sk_msg,sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr forconsistency.Note this syzkaller crash was reported in the "Closes" link below, whichused to be about a different bug, fixed incommit fce7bd8e385a ("bpf/verifier: Handle BPF_LOAD_ACQ instructionsin insn_def_regno()"). Because syzbot somehow confused the two bugs,the new crash and repro didn't get reported to the mailing list.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:exfat: add cluster chain loop check for dirAn infinite loop may occur if the following conditions occur due tofile system corruption.(1) Condition for exfat_count_dir_entries() to loop infinitely. - The cluster chain includes a loop. - There is no UNUSED entry in the cluster chain.(2) Condition for exfat_create_upcase_table() to loop infinitely. - The cluster chain of the root directory includes a loop. - There are no UNUSED entry and up-case table entry in the cluster chain of the root directory.(3) Condition for exfat_load_bitmap() to loop infinitely. - The cluster chain of the root directory includes a loop. - There are no UNUSED entry and bitmap entry in the cluster chain of the root directory.(4) Condition for exfat_find_dir_entry() to loop infinitely. - The cluster chain includes a loop. - The unused directory entries were exhausted by some operation.(5) Condition for exfat_check_dir_empty() to loop infinitely. - The cluster chain includes a loop. - The unused directory entries were exhausted by some operation. - All files and sub-directories under the directory are deleted.This commit adds checks to break the above infinite loop.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Destroy KFD debugfs after destroy KFD wqSince KFD proc content was moved to kernel debugfs, we can't destroy KFDdebugfs before kfd_process_destroy_wq. Move kfd_process_destroy_wq priorto kfd_debugfs_fini to fix a kernel NULL pointer problem. It happenswhen /sys/kernel/debug/kfd was already destroyed in kfd_debugfs_fini butkfd_process_destroy_wq calls kfd_debugfs_remove_process. This line debugfs_remove_recursive(entry->proc_dentry);tries to remove /sys/kernel/debug/kfd/proc/
while/sys/kernel/debug/kfd is already gone. It hangs the kernel by kernelNULL pointer.(cherry picked from commit 0333052d90683d88531558dcfdbf2525cc37c233)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not allow relocation of partially dropped subvolumes[BUG]There is an internal report that balance triggered transaction abort,with the following call trace: item 85 key (594509824 169 0) itemoff 12599 itemsize 33 extent refs 1 gen 197740 flags 2 ref#0: tree block backref root 7 item 86 key (594558976 169 0) itemoff 12566 itemsize 33 extent refs 1 gen 197522 flags 2 ref#0: tree block backref root 7 ... BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0 BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117 ------------[ cut here ]------------ BTRFS: Transaction aborted (error -117) WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]And btrfs check doesn't report anything wrong related to the extenttree.[CAUSE]The cause is a little complex, firstly the extent tree indeed doesn'thave the backref for 594526208.The extent tree only have the following two backrefs around that bytenron-disk: item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33 refs 1 gen 197740 flags TREE_BLOCK tree block skinny level 0 (176 0x7) tree block backref root CSUM_TREE item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33 refs 1 gen 197522 flags TREE_BLOCK tree block skinny level 0 (176 0x7) tree block backref root CSUM_TREEBut the such missing backref item is not an corruption on disk, as theoffending delayed ref belongs to subvolume 934, and that subvolume isbeing dropped: item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439 generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328 last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0 drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2 level 2 generation_v2 198229And that offending tree block 594526208 is inside the dropped range ofthat subvolume. That explains why there is no backref item for thatbytenr and why btrfs check is not reporting anything wrong.But this also shows another problem, as btrfs will do all the orphansubvolume cleanup at a read-write mount.So half-dropped subvolume should not exist after an RW mount, andbalance itself is also exclusive to subvolume cleanup, meaning weshouldn't hit a subvolume half-dropped during relocation.The root cause is, there is no orphan item for this subvolume.In fact there are 5 subvolumes from around 2021 that have the sameproblem.It looks like the original report has some older kernels running, andcaused those zombie subvolumes.Thankfully upstream commit 8d488a8c7ba2 ("btrfs: fix subvolume/snapshotdeletion not triggered on mount") has long fixed the bug.[ENHANCEMENT]For repairing such old fs, btrfs-progs will be enhanced.Considering how delayed the problem will show up (at run delayed reftime) and at that time we have to abort transaction already, it is toolate.Instead here we reject any half-dropped subvolume for reloc tree at theearliest time, preventing confusion and extra time wasted on debuggingsimilar bugs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: APEI: send SIGBUS to current task if synchronous memory error not recoveredIf a synchronous error is detected as a result of user-space processtriggering a 2-bit uncorrected error, the CPU will take a synchronouserror exception such as Synchronous External Abort (SEA) on Arm64. Thekernel will queue a memory_failure() work which poisons the relatedpage, unmaps the page, and then sends a SIGBUS to the process, so thata system wide panic can be avoided.However, no memory_failure() work will be queued when abnormalsynchronous errors occur. These errors can include situations likeinvalid PA, unexpected severity, no memory failure config support,invalid GUID section, etc. In such a case, the user-space process willtrigger SEA again. This loop can potentially exceed the platformfirmware threshold or even trigger a kernel hard lockup, leading to asystem reboot.Fix it by performing a force kill if no memory_failure() work is queuedfor synchronous errors.[ rjw: Changelog edits ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: mdt_loader: Ensure we don't read past the ELF headerWhen the MDT loader is used in remoteproc, the ELF header is sanitizedbeforehand, but that's not necessary the case for other clients.Validate the size of the firmware buffer to ensure that we don't readpast the end as we iterate over the header. e_phentsize and e_shentsizeare validated as well, to ensure that the assumptions about step size inthe traversal are valid.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/s390: Make attach succeed when the device was surprise removedWhen a PCI device is removed with surprise hotplug, there may still beattempts to attach the device to the default domain as part of tear downvia (__iommu_release_dma_ownership()), or because the removal happensduring probe (__iommu_probe_device()). In both cases zpci_register_ioat()fails with a cc value indicating that the device handle is invalid. Thisis because the device is no longer part of the instance as far as thehypervisor is concerned.Currently this leads to an error return and s390_iommu_attach_device()fails. This triggers the WARN_ON() in __iommu_group_set_domain_nofail()because attaching to the default domain must never fail.With the device fenced by the hypervisor no DMAs to or from memory arepossible and the IOMMU translations have no effect. Proceed as if theregistration was successful and let the hotplug event handling clean upthe device.This is similar to how devices in the error state are handled sincecommit 59bbf596791b ("iommu/s390: Make attach succeed even if the deviceis in error state") except that for removal the domain will not beregistered later. This approach was also previously discussed at thelink.Handle both cases, error state and removal, in a helper which checks ifthe error needs to be propagated or ignored. Avoid magic numbercondition codes by using the pre-existing, but never used, defines forPCI load/store condition codes and rename them to reflect that theyapply to all PCI instructions.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nexthop: Forbid FDB status change while nexthop is in a groupThe kernel forbids the creation of non-FDB nexthop groups with FDBnexthops: # ip nexthop add id 1 via 192.0.2.1 fdb # ip nexthop add id 2 group 1 Error: Non FDB nexthop group cannot have fdb nexthops.And vice versa: # ip nexthop add id 3 via 192.0.2.2 dev dummy1 # ip nexthop add id 4 group 3 fdb Error: FDB nexthop group can only have fdb nexthops.However, as long as no routes are pointing to a non-FDB nexthop group,the kernel allows changing the type of a nexthop from FDB to non-FDB andvice versa: # ip nexthop add id 5 via 192.0.2.2 dev dummy1 # ip nexthop add id 6 group 5 # ip nexthop replace id 5 via 192.0.2.2 fdb # echo $? 0This configuration is invalid and can result in a NPD [1] since FDBnexthops are not associated with a nexthop device: # ip route add 198.51.100.1/32 nhid 6 # ping 198.51.100.1Fix by preventing nexthop FDB status change while the nexthop is in agroup: # ip nexthop add id 7 via 192.0.2.2 dev dummy1 # ip nexthop add id 8 group 7 # ip nexthop replace id 7 via 192.0.2.2 fdb Error: Cannot change nexthop FDB status while in a group.[1]BUG: kernel NULL pointer dereference, address: 00000000000003c0[...]Oops: Oops: 0000 [#1] SMPCPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014RIP: 0010:fib_lookup_good_nhc+0x1e/0x80[...]Call Trace: fib_table_lookup+0x541/0x650 ip_route_output_key_hash_rcu+0x2ea/0x970 ip_route_output_key_hash+0x55/0x80 __ip4_datagram_connect+0x250/0x330 udp_connect+0x2b/0x60 __sys_connect+0x9c/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0xa4/0x2a0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before releaseThe fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can beNULL even after EPF initialization. Then it is prudent to check thatthey have non-NULL values before releasing the channels. Add the checksin pci_epf_test_clean_dma_chan().Without the checks, NULL pointer dereferences happen and they can leadto a kernel panic in some cases: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Call trace: dma_release_channel+0x2c/0x120 (P) pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test] pci_epc_deinit_notify+0x74/0xc0 tegra_pcie_ep_pex_rst_irq+0x250/0x5d8 irq_thread_fn+0x34/0xb8 irq_thread+0x18c/0x2e8 kthread+0x14c/0x210 ret_from_fork+0x10/0x20[mani: trimmed the stack trace]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: Refactor bind path to use __free()After an bind/unbind cycle, the ncm->notify_req is left stale. If asubsequent bind fails, the unified error label attempts to free thisstale request, leading to a NULL pointer dereference when accessingep->ops->free_request.Refactor the error handling in the bind path to use the __free()automatic cleanup mechanism.Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020Call trace: usb_ep_free_request+0x2c/0xec ncm_bind+0x39c/0x3dc usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: check kobject state_in_sysfs before deleting in blk_mq_unregister_hctxIn __blk_mq_update_nr_hw_queues() the return value ofblk_mq_sysfs_register_hctxs() is not checked. If sysfs creation for hctxfails, later changing the number of hw_queues or removing disk willtrigger the following warning: kernfs: can not remove 'nr_tags', no directory WARNING: CPU: 2 PID: 637 at fs/kernfs/dir.c:1707 kernfs_remove_by_name_ns+0x13f/0x160 Call Trace: remove_files.isra.1+0x38/0xb0 sysfs_remove_group+0x4d/0x100 sysfs_remove_groups+0x31/0x60 __kobject_del+0x23/0xf0 kobject_del+0x17/0x40 blk_mq_unregister_hctx+0x5d/0x80 blk_mq_sysfs_unregister_hctxs+0x94/0xd0 blk_mq_update_nr_hw_queues+0x124/0x760 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_submit_queues_store+0x92/0x120 [null_blk]kobjct_del() was called unconditionally even if sysfs creation failed.Fix it by checkig the kobject creation statusbefore deleting it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pid: Add a judgment for ns null in pid_nr_ns__task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) {Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.For example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : __task_pid_nr_ns+0x74/0xd0 lr : __task_pid_nr_ns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 Call trace: __task_pid_nr_ns+0x74/0xd0 ... __handle_irq_event_percpu+0xd4/0x284 handle_irq_event+0x48/0xb0 handle_fasteoi_irq+0x160/0x2d8 generic_handle_domain_irq+0x44/0x60 gic_handle_irq+0x4c/0x114 call_on_irq_stack+0x3c/0x74 do_interrupt_handler+0x4c/0x84 el1_interrupt+0x34/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c account_kernel_stack+0x60/0x144 exit_task_stack_account+0x1c/0x80 do_exit+0x7e4/0xaf8 ... get_signal+0x7bc/0x8d8 do_notify_resume+0x128/0x828 el0_svc+0x6c/0x70 el0t_64_sync_handler+0x68/0xbc el0t_64_sync+0x1a8/0x1ac Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_connmark: initialize struct tc_ife to fix kernel leakIn tcf_connmark_dump(), the variable 'opt' was partially initialized using adesignatied initializer. While the padding bytes are reamineduninitialized. nla_put() copies the entire structure into anetlink message, these uninitialized bytes leaked to userspace.Initialize the structure with memset before assigning its fieldsto ensure all members and padding are cleared prior to beign copied.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: validate skb length for unknown CC opcodeIn hci_cmd_complete_evt(), if the command complete event has an unknownopcode, we assume the first byte of the remaining skb->data contains thereturn status. However, parameter data has previously been pulled inhci_event_func(), which may leave the skb empty. If so, using skb->data[0]for the return status uses un-init memory.The fix is to check skb->len before using skb->data.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check NULL before accessing[WHAT]IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomicfails with NULL pointer dereference. This can be reproduced withboth an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ...(cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flagsWhen a filesystem is being automounted, it needs to preserve theuser-set superblock mount options, such as the "ro" flag.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libncurses6 > 0-0 (version in image is 6.1-150000.5.33.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:team: fix check for port enabled in team_queue_override_port_prio_changed()There has been a syzkaller bug reported recently with the followingtrace:list_del corruption, ffff888058bea080->prev is LIST_POISON2 (dead000000000122)------------[ cut here ]------------kernel BUG at lib/list_debug.c:59!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTICPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59Code: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ffRSP: 0018:ffffc9000d49f370 EFLAGS: 00010286RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005RBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000R10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0Call Trace: __list_del_entry_valid include/linux/list.h:132 [inline] __list_del_entry include/linux/list.h:223 [inline] list_del_rcu include/linux/rculist.h:178 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline] team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline] team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534 team_option_set drivers/net/team/team_core.c:376 [inline] team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653 genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2630 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684 __sys_sendmsg+0x16d/0x220 net/socket.c:2716 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe problem is in this flow:1) Port is enabled, queue_id != 0, in qom_list2) Port gets disabled -> team_port_disable() -> team_queue_override_port_del() -> del (removed from list)3) Port is disabled, queue_id != 0, not in any list4) Priority changes -> team_queue_override_port_prio_changed() -> checks: port disabled && queue_id != 0 -> calls del - hits the BUG as it is removed alreadyTo fix this, change the check in team_queue_override_port_prio_changed()so it returns early if port is not enabled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Free sp in error path to fix system crashSystem crash seen during load/unload test in a loop,[61110.449331] qla2xxx [0000:27:00.0]-0042:0: Disabled MSI-X.[61110.467494] =============================================================================[61110.467498] BUG qla2xxx_srbs (Tainted: G OE -------- --- ): Objects remaining in qla2xxx_srbs on __kmem_cache_shutdown()[61110.467501] -----------------------------------------------------------------------------[61110.467502] Slab 0x000000000ffc8162 objects=51 used=1 fp=0x00000000e25d3d85 flags=0x57ffffc0010200(slab|head|node=1|zone=2|lastcpupid=0x1fffff)[61110.467509] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1[61110.467513] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023[61110.467515] Call Trace:[61110.467516] [61110.467519] dump_stack_lvl+0x34/0x48[61110.467526] slab_err.cold+0x53/0x67[61110.467534] __kmem_cache_shutdown+0x16e/0x320[61110.467540] kmem_cache_destroy+0x51/0x160[61110.467544] qla2x00_module_exit+0x93/0x99 [qla2xxx][61110.467607] ? __do_sys_delete_module.constprop.0+0x178/0x280[61110.467613] ? syscall_trace_enter.constprop.0+0x145/0x1d0[61110.467616] ? do_syscall_64+0x5c/0x90[61110.467619] ? exc_page_fault+0x62/0x150[61110.467622] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd[61110.467626] [61110.467627] Disabling lock debugging due to kernel taint[61110.467635] Object 0x0000000026f7e6e6 @offset=16000[61110.467639] ------------[ cut here ]------------[61110.467639] kmem_cache_destroy qla2xxx_srbs: Slab cache still has objects when called from qla2x00_module_exit+0x93/0x99 [qla2xxx][61110.467659] WARNING: CPU: 53 PID: 455206 at mm/slab_common.c:520 kmem_cache_destroy+0x14d/0x160[61110.467718] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G B OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1[61110.467720] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023[61110.467721] RIP: 0010:kmem_cache_destroy+0x14d/0x160[61110.467724] Code: 99 7d 07 00 48 89 ef e8 e1 6a 07 00 eb b3 48 8b 55 60 48 8b 4c 24 20 48 c7 c6 70 fc 66 90 48 c7 c7 f8 ef a1 90 e8 e1 ed 7c 00 <0f> 0b eb 93 c3 cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 55 48 89[61110.467725] RSP: 0018:ffffa304e489fe80 EFLAGS: 00010282[61110.467727] RAX: 0000000000000000 RBX: ffffffffc0d9a860 RCX: 0000000000000027[61110.467729] RDX: ffff8fd5ff9598a8 RSI: 0000000000000001 RDI: ffff8fd5ff9598a0[61110.467730] RBP: ffff8fb6aaf78700 R08: 0000000000000000 R09: 0000000100d863b7[61110.467731] R10: ffffa304e489fd20 R11: ffffffff913bef48 R12: 0000000040002000[61110.467731] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000[61110.467733] FS: 00007f64c89fb740(0000) GS:ffff8fd5ff940000(0000) knlGS:0000000000000000[61110.467734] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[61110.467735] CR2: 00007f0f02bfe000 CR3: 00000020ad6dc005 CR4: 0000000000770ee0[61110.467736] PKRU: 55555554[61110.467737] Call Trace:[61110.467738] [61110.467739] qla2x00_module_exit+0x93/0x99 [qla2xxx][61110.467755] ? __do_sys_delete_module.constprop.0+0x178/0x280Free sp in the error path to fix the crash.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: Avoid creating sub-groups asynchronouslyThe asynchronous creation of sub-groups by a delayed work could lead to aNULL pointer dereference when the driver directory is removed before thework completes.The crash can be easily reproduced with the following commands: # cd /sys/kernel/config/pci_ep/functions/pci_epf_test # for i in {1..20}; do mkdir test && rmdir test; done BUG: kernel NULL pointer dereference, address: 0000000000000088 ... Call Trace: configfs_register_group+0x3d/0x190 pci_epf_cfs_work+0x41/0x110 process_one_work+0x18f/0x350 worker_thread+0x25a/0x3a0Fix this issue by using configfs_add_default_group() API which does nothave the deadlock problem as configfs_register_group() and does not requirethe delayed work handler.[mani: slightly reworded the description and added stable list]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Delay module unload while fabric scan in progressSystem crash seen during load/unload test in a loop.[105954.384919] RBP: ffff914589838dc0 R08: 0000000000000000 R09: 0000000000000086[105954.384920] R10: 000000000000000f R11: ffffa31240904be5 R12: ffff914605f868e0[105954.384921] R13: ffff914605f86910 R14: 0000000000008010 R15: 00000000ddb7c000[105954.384923] FS: 0000000000000000(0000) GS:ffff9163fec40000(0000) knlGS:0000000000000000[105954.384925] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[105954.384926] CR2: 000055d31ce1d6a0 CR3: 0000000119f5e001 CR4: 0000000000770ee0[105954.384928] PKRU: 55555554[105954.384929] Call Trace:[105954.384931] [105954.384934] qla24xx_sp_unmap+0x1f3/0x2a0 [qla2xxx][105954.384962] ? qla_async_scan_sp_done+0x114/0x1f0 [qla2xxx][105954.384980] ? qla24xx_els_ct_entry+0x4de/0x760 [qla2xxx][105954.384999] ? __wake_up_common+0x80/0x190[105954.385004] ? qla24xx_process_response_queue+0xc2/0xaa0 [qla2xxx][105954.385023] ? qla24xx_msix_rsp_q+0x44/0xb0 [qla2xxx][105954.385040] ? __handle_irq_event_percpu+0x3d/0x190[105954.385044] ? handle_irq_event+0x58/0xb0[105954.385046] ? handle_edge_irq+0x93/0x240[105954.385050] ? __common_interrupt+0x41/0xa0[105954.385055] ? common_interrupt+0x3e/0xa0[105954.385060] ? asm_common_interrupt+0x22/0x40The root cause of this was that there was a free (dma_free_attrs) in theinterrupt context. There was a device discovery/fabric scan inprogress. A module unload was issued which set the UNLOADING flag. Aspart of the discovery, after receiving an interrupt a work queue wasscheduled (which involved a work to be queued). Since the UNLOADINGflag is set, the work item was not allocated and the mapped memory hadto be freed. The free occurred in interrupt context leading to systemcrash. Delay the driver unload until the fabric scan is complete toavoid the crash.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: detach and close netdevs while handling a resetProtect the reset path from callbacks by setting the netdevs to detachedstate and close any netdevs in UP state until the reset handling hascompleted. During a reset, the driver will de-allocate resources for thevport, and there is no guarantee that those will recover, which is why theexisting vport_ctrl_lock does not provide sufficient protection.idpf_detach_and_close() is called right before reset handling. If thereset handling succeeds, the netdevs state is recovered via call toidpf_attach_and_open(). If the reset handling fails the netdevs remaindown. The detach/down calls are protected with RTNL lock to avoid racingwith callbacks. On the recovery side the attach can be done withoutholding the RTNL lock as there are no callbacks expected at that point,due to detach/close always being done first in that flow.The previous logic restoring the netdevs state based on theIDPF_VPORT_UP_REQUESTED flag in the init task is not needed anymore, hencethe removal of idpf_set_vport_state(). The IDPF_VPORT_UP_REQUESTED isstill being used to restore the state of the netdevs following the reset,but has no use outside of the reset handling flow.idpf_init_hard_reset() is converted to void, since it was used as such andthere is no error handling being done based on its return value.Before this change, invoking hard and soft resets simultaneously willcause the driver to lose the vport state:ip -br a UPecho 1 > /sys/class/net/ens801f0/device/reset& \ethtool -L ens801f0 combined 8ip -br a DOWNip link set upip -br a DOWNAlso in case of a failure in the reset path, the netdev is leftexposed to external callbacks, while vport resources are notinitialized, leading to a crash on subsequent ifup/down:[408471.398966] idpf 0000:83:00.0: HW reset detected[408471.411744] idpf 0000:83:00.0: Device HW Reset initiated[408472.277901] idpf 0000:83:00.0: The driver was unable to contact the device's firmware. Check that the FW is running. Driver state= 0x2[408508.125551] BUG: kernel NULL pointer dereference, address: 0000000000000078[408508.126112] #PF: supervisor read access in kernel mode[408508.126687] #PF: error_code(0x0000) - not-present page[408508.127256] PGD 2aae2f067 P4D 0[408508.127824] Oops: Oops: 0000 [#1] SMP NOPTI...[408508.130871] RIP: 0010:idpf_stop+0x39/0x70 [idpf]...[408508.139193] Call Trace:[408508.139637] [408508.140077] __dev_close_many+0xbb/0x260[408508.140533] __dev_change_flags+0x1cf/0x280[408508.140987] netif_change_flags+0x26/0x70[408508.141434] dev_change_flags+0x3d/0xb0[408508.141878] devinet_ioctl+0x460/0x890[408508.142321] inet_ioctl+0x18e/0x1d0[408508.142762] ? _copy_to_user+0x22/0x70[408508.143207] sock_do_ioctl+0x3d/0xe0[408508.143652] sock_ioctl+0x10e/0x330[408508.144091] ? find_held_lock+0x2b/0x80[408508.144537] __x64_sys_ioctl+0x96/0xe0[408508.144979] do_syscall_64+0x79/0x3d0[408508.145415] entry_SYSCALL_64_after_hwframe+0x76/0x7e[408508.145860] RIP: 0033:0x7f3e0bb4caff
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: Fix RSS LUT NULL ptr issue after soft resetDuring soft reset, the RSS LUT is freed and not restored unless theinterface is up. If an ethtool command that accesses the rss lut isattempted immediately after reset, it will result in NULL ptrdereference. Also, there is no need to reset the rss lut if the soft resetdoes not involve queue count change.After soft reset, set the RSS LUT to default values based on the updatedqueue count only if the reset was a result of a queue count change andthe LUT was not configured by the user. In all other cases, don't touchthe LUT.Steps to reproduce:** Bring the interface down (if up)ifconfig eth1 down** update the queue count (eg., 27->20)ethtool -L eth1 combined 20** display the RSS LUTethtool -x eth1[82375.558338] BUG: kernel NULL pointer dereference, address: 0000000000000000[82375.558373] #PF: supervisor read access in kernel mode[82375.558391] #PF: error_code(0x0000) - not-present page[82375.558408] PGD 0 P4D 0[82375.558421] Oops: Oops: 0000 [#1] SMP NOPTI[82375.558516] RIP: 0010:idpf_get_rxfh+0x108/0x150 [idpf][82375.558786] Call Trace:[82375.558793] [82375.558804] rss_prepare.isra.0+0x187/0x2a0[82375.558827] rss_prepare_data+0x3a/0x50[82375.558845] ethnl_default_doit+0x13d/0x3e0[82375.558863] genl_family_rcv_msg_doit+0x11f/0x180[82375.558886] genl_rcv_msg+0x1ad/0x2b0[82375.558902] ? __pfx_ethnl_default_doit+0x10/0x10[82375.558920] ? __pfx_genl_rcv_msg+0x10/0x10[82375.558937] netlink_rcv_skb+0x58/0x100[82375.558957] genl_rcv+0x2c/0x50[82375.558971] netlink_unicast+0x289/0x3e0[82375.558988] netlink_sendmsg+0x215/0x440[82375.559005] __sys_sendto+0x234/0x240[82375.559555] __x64_sys_sendto+0x28/0x30[82375.560068] x64_sys_call+0x1909/0x1da0[82375.560576] do_syscall_64+0x7a/0xfa0[82375.561076] ? clear_bhb_loop+0x60/0xb0[82375.561567] entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_ife: avoid possible NULL dereftcf_ife_encode() must make sure ife_encode() does not return NULL.syzbot reported:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full)Call Trace: ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101 tcf_ife_encode net/sched/act_ife.c:841 [inline] tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877 tc_act include/net/tc_wrapper.h:130 [inline] tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152 tcf_exts_exec include/net/pkt_cls.h:349 [inline] mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1764 [inline] tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860 multiq_classify net/sched/sch_multiq.c:39 [inline] multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66 dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147 __dev_xmit_skb net/core/dev.c:4262 [inline] __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: spi-sprd-adi: Fix double free in probe error pathThe driver currently uses spi_alloc_host() to allocate the controllerbut registers it using devm_spi_register_controller().If devm_register_restart_handler() fails, the code jumps to theput_ctlr label and calls spi_controller_put(). However, since thecontroller was registered via a devm function, the device core willautomatically call spi_controller_put() again when the probe fails.This results in a double-free of the spi_controller structure.Fix this by switching to devm_spi_alloc_host() and removing themanual spi_controller_put() call.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_listWhen the parameter pmac_id_valid argument of be_cmd_get_mac_from_list() isset to false, the driver may request the PMAC_ID from the firmware of thenetwork card, and this function will store that PMAC_ID at the providedaddress pmac_id. This is the contract of this function.However, there is a location within the driver where bothpmac_id_valid == false and pmac_id == NULL are being passed. This couldresult in dereferencing a NULL pointer.To resolve this issue, it is necessary to pass the address of a stubvariable to the function.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Disable MMIO access during SMU Mode 1 resetDuring Mode 1 reset, the ASIC undergoes a reset cycle and becomestemporarily inaccessible via PCIe. Any attempt to access MMIO registersduring this window (e.g., from interrupt handlers or other driver threads)can result in uncompleted PCIe transactions, leading to NMI panics orsystem hangs.To prevent this, set the `no_hw_access` flag to true immediately aftertriggering the reset. This signals other driver components to skipregister accesses while the device is offline.A memory barrier `smp_mb()` is added to ensure the flag update isglobally visible to all cores before the driver enters the sleep/waitstate.(cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthopWhen a standalone IPv6 nexthop object is created with a loopback device(e.g., "ip -6 nexthop add id 100 dev lo"), fib6_nh_init() misclassifiesit as a reject route. This is because nexthop objects have no destinationprefix (fc_dst=::), causing fib6_is_reject() to match any loopbacknexthop. The reject path skips fib_nh_common_init(), leavingnhc_pcpu_rth_output unallocated. If an IPv4 route later references thisnexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output andpanics.Simplify the check in fib6_nh_init() to only match explicit rejectroutes (RTF_REJECT) instead of using fib6_is_reject(). The loopbackpromotion heuristic in fib6_is_reject() is handled separately byip6_route_info_create_nh(). After this change, the three cases behaveas follows:1. Explicit reject route ("ip -6 route add unreachable 2001:db8::/64"): RTF_REJECT is set, enters reject path, skips fib_nh_common_init(). No behavior change.2. Implicit loopback reject route ("ip -6 route add 2001:db8::/32 dev lo"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. ip6_route_info_create_nh() still promotes it to reject afterward. nhc_pcpu_rth_output is allocated but unused, which is harmless.3. Standalone nexthop object ("ip -6 nexthop add id 100 dev lo"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. nhc_pcpu_rth_output is properly allocated, fixing the crash when IPv4 routes reference this nexthop.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: macb: use the current queue number for statsThere's a potential mismatch between the memory reserved for statisticsand the amount of memory written.gem_get_sset_count() correctly computes the number of stats based on theactive queues, whereas gem_get_ethtool_stats() indiscriminately copiesdata using the maximum number of queues, and in the case the number ofactive queues is less than MACB_MAX_QUEUES, this results in a OOB writeas observed in the KASAN splat.==================================================================BUG: KASAN: vmalloc-out-of-bounds in gem_get_ethtool_stats+0x54/0x78 [macb]Write of size 760 at addr ffff80008080b000 by task ethtool/1027CPU: [...]Tainted: [E]=UNSIGNED_MODULEHardware name: raspberrypi rpi/rpi, BIOS 2025.10 10/01/2025Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 print_report+0x384/0x5e0 kasan_report+0xa0/0xf0 kasan_check_range+0xe8/0x190 __asan_memcpy+0x54/0x98 gem_get_ethtool_stats+0x54/0x78 [macb 926c13f3af83b0c6fe64badb21ec87d5e93fcf65] dev_ethtool+0x1220/0x38c0 dev_ioctl+0x4ac/0xca8 sock_do_ioctl+0x170/0x1d8 sock_ioctl+0x484/0x5d8 __arm64_sys_ioctl+0x12c/0x1b8 invoke_syscall+0xd4/0x258 el0_svc_common.constprop.0+0xb4/0x240 do_el0_svc+0x48/0x68 el0_svc+0x40/0xf8 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8The buggy address belongs to a 1-page vmalloc region starting at 0xffff80008080b000 allocated at dev_ethtool+0x11f0/0x38c0The buggy address belongs to the physical page:page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff00000a333000 pfn:0xa333flags: 0x7fffc000000000(node=0|zone=0|lastcpupid=0x1ffff)raw: 007fffc000000000 0000000000000000 dead000000000122 0000000000000000raw: ffff00000a333000 0000000000000000 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffff80008080b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80008080b100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>ffff80008080b180: 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffff80008080b200: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffff80008080b280: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8==================================================================Fix it by making sure the copied size only considers the active number ofqueues.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: jq is a command-line JSON processor. In 1.8.1 and earlier, jq accepts embedded NUL bytes in import paths at the jq-language level, but later resolves those paths through C string operations during module and data-file lookup. This creates a mismatch between the logical import string that policy or audit code may validate and the on-disk path that jq actually opens.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- vim > 0-0 (version in image is 9.2.0280-150500.20.46.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libsqlite3-0 > 0-0 (version in image is 3.51.3-150000.3.39.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dpaa2-switch: prevent ZERO_SIZE_PTR dereference when num_ifs is zeroThe driver allocates arrays for ports, FDBs, and filter blocks usingkcalloc() with ethsw->sw_attr.num_ifs as the element count. When thedevice reports zero interfaces (either due to hardware configurationor firmware issues), kcalloc(0, ...) returns ZERO_SIZE_PTR (0x10)instead of NULL.Later in dpaa2_switch_probe(), the NAPI initialization unconditionallyaccesses ethsw->ports[0]->netdev, which attempts to dereferenceZERO_SIZE_PTR (address 0x10), resulting in a kernel panic.Add a check to ensure num_ifs is greater than zero after retrievingdevice attributes. This prevents the zero-sized allocations andsubsequent invalid pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bridge: br_nd_send: linearize skb before parsing ND optionsbr_nd_send() parses neighbour discovery options from ns->opt[] andassumes that these options are in the linear part of request.Its callers only guarantee that the ICMPv6 header and target addressare available, so the option area can still be non-linear. Parsingns->opt[] in that case can access data past the linear buffer.Linearize request before option parsing and derive ns from the linearnetwork header.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: pvrusb2: fix URB leak in pvr2_send_request_exWhen pvr2_send_request_ex() submits a write URB successfully but fails tosubmit the read URB (e.g. returns -ENOMEM), it returns immediately withoutwaiting for the write URB to complete. Since the driver reuses the sameURB structure, a subsequent call to pvr2_send_request_ex() attempts tosubmit the still-active write URB, triggering a 'URB submitted whileactive' warning in usb_submit_urb().Fix this by ensuring the write URB is unlinked and waited upon if the readURB submission fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: Bluetooth LE and BR/EDR Secure Connections pairing and Secure Simple Pairing using the Passkey entry protocol in Bluetooth Core Specifications 2.1 through 5.3 may permit an unauthenticated man-in-the-middle attacker to identify the Passkey used during pairing by reflection of a crafted public key with the same X coordinate as the offered public key and by reflection of the authentication evidence of the initiating device, potentially permitting this attacker to complete authenticated pairing with the responding device using the correct Passkey for the pairing session. This is a related issue to CVE-2020-26558.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_netlink: Fix shift out of bounds in group mask calculationWhen a netlink message is received, netlink_recvmsg() fills in the addressof the sender. One of the fields is the 32-bit bitfield nl_groups, whichcarries the multicast group on which the message was received. The leastsignificant bit corresponds to group 1, and therefore the highest groupthat the field can represent is 32. Above that, the UB sanitizer flags theout-of-bounds shift attempts.Which bits end up being set in such case is implementation defined, butit's either going to be a wrong non-zero value, or zero, which is at leastnot misleading. Make the latter choice deterministic by always setting to 0for higher-numbered multicast groups.To get information about membership in groups >= 32, userspace is expectedto use nl_pktinfo control messages[0], which are enabled by NETLINK_PKTINFOsocket option.[0] https://lwn.net/Articles/147608/The way to trigger this issue is e.g. through monitoring the BRVLAN group: # bridge monitor vlan & # ip link add name br type bridgeWhich produces the following citation: UBSAN: shift-out-of-bounds in net/netlink/af_netlink.c:162:19 shift exponent 32 is too large for 32-bit type 'int'
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powercap: intel_rapl: fix UBSAN shift-out-of-bounds issueWhen value < time_unit, the parameter of ilog2() will be zero andthe return value is -1. u64(-1) is too large for shift exponentand then will trigger shift-out-of-bounds:shift exponent 18446744073709551615 is too large for 32-bit type 'int'Call Trace: rapl_compute_time_window_core rapl_write_data_raw set_time_window store_constraint_time_window_us
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:resource: fix region_intersects() vs add_memory_driver_managed()On a system with CXL memory, the resource tree (/proc/iomem) related toCXL memory may look like something as follows.490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem)Because drivers/dax/kmem.c calls add_memory_driver_managed() duringonlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXLWindow X". This confuses region_intersects(), which expects all "SystemRAM" resources to be at the top level of iomem_resource. This can lead tobugs.For example, when the following command line is executed to write somememory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/sthe command fails as expected. However, the error code is wrong. Itshould be "Operation not permitted" instead of "Bad address". Moreseriously, the /dev/mem permission checking in devmem_is_allowed() passesincorrectly. Although the accessing is prevented later because ioremap()isn't allowed to map system RAM, it is a potential security issue. Duringcommand executing, the following warning is reported in the kernel log forcalling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53The details of command execution process are as follows. In the aboveresource tree, "System RAM" is a descendant of "CXL Window 0" instead of atop level resource. So, region_intersects() will report no System RAMresources in the CXL memory region incorrectly, because it only checks thetop level resources. Consequently, devmem_is_allowed() will return 1(allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject theaccess.So, region_intersects() needs to be fixed to work correctly with theresource tree with "System RAM" not at top level as above. To fix it, ifwe found a unmatched resource in the top level, we will continue to searchmatched resources in its descendant resources. So, we will not miss anymatched resources in resource tree anymore.In the new implementation, an example resource tree|------------- "CXL Window 0" ------------||-- "System RAM" --|will behave similar as the following fake resource tree forregion_intersects(, IORESOURCE_SYSTEM_RAM, ),|-- "System RAM" --||-- "CXL Window 0a" --|Where "CXL Window 0a" is part of the original "CXL Window 0" thatisn't covered by "System RAM".
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: validate l_tree_depth to avoid out-of-bounds accessThe l_tree_depth field is 16-bit (__le16), but the actual maximum depth islimited to OCFS2_MAX_PATH_DEPTH.Add a check to prevent out-of-bounds access if l_tree_depth has an invalidvalue, which may occur when reading from a corrupted mounted disk [1].
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: When switching to other buffers using the :all command and visual mode still being active, this may cause a heap-buffer overflow, because Vim does not properly end visual mode and therefore may try to access beyond the end of a line in a buffer. In Patch 9.1.1003 Vim will correctly reset the visual mode before opening other windows and buffers and therefore fix this bug. In addition it does verify that it won't try to access a position if the position is greater than the corresponding buffer line. Impact is medium since the user must have switched on visual mode when executing the :all ex command. The Vim project would like to thank github user gandalf4a for reporting this issue. The issue has been fixed as of Vim patch v9.1.1003
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- vim > 0-0 (version in image is 9.2.0280-150500.20.46.1).
-
Description: Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- vim > 0-0 (version in image is 9.2.0280-150500.20.46.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- openssh > 0-0 (version in image is 8.4p1-150300.3.57.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/mce: Work around an erratum on fast string copy instructionsA rare kernel panic scenario can happen when the following conditionsare met due to an erratum on fast string copy instructions:1) An uncorrected error.2) That error must be in first cache line of a page.3) Kernel must execute page_copy from the page immediately before thatpage.The fast string copy instructions ("REP; MOVS*") could consume anuncorrectable memory error in the cache line _right after_ the desiredregion to copy and raise an MCE.Bit 0 of MSR_IA32_MISC_ENABLE can be cleared to disable fast stringcopy and will avoid such spurious machine checks. However, that is lesspreferable due to the permanent performance impact. Considering memorypoison is rare, it's desirable to keep fast string copy enabled until anMCE is seen.Intel has confirmed the following:1. The CPU erratum of fast string copy only applies to Skylake,Cascade Lake and Cooper Lake generations.Directly return from the MCE handler:2. Will result in complete execution of the "REP; MOVS*" with no dataloss or corruption.3. Will not result in another MCE firing on the next poisoned cache linedue to "REP; MOVS*".4. Will resume execution from a correct point in code.5. Will result in the same instruction that triggered the MCE firing asecond MCE immediately for any other software recoverable data fetcherrors.6. Is not safe without disabling the fast string copy, as the next faststring copy of the same buffer on the same CPU would result in a PANICMCE.This should mitigate the erratum completely with the only caveat thatthe fast string copy is disabled on the affected hyper thread thusperformance degradation.This is still better than the OS crashing on MCEs raised on anirrelevant process due to "REP; MOVS*' accesses in a kernel context,e.g., copy_page.Injected errors on 1st cache line of 8 anonymous pages of process'proc1' and observed MCE consumption from 'proc2' with no panic(directly returned).Without the fix, the host panicked within a few minutes on arandom 'proc2' process due to kernel access from copy_page. [ bp: Fix comment style + touch ups, zap an unlikely(), improve the quirk function's readability. ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:loop: implement ->free_diskEnsure that the lo_device which is stored in the gendisk privatedata is valid until the gendisk is freed. Currently the loop driveruses a lot of effort to make sure a device is not freed when it isstill in use, but to to fix a potential deadlock this will be relaxeda bit soon.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/tunnel: wait until all sk_user_data reader finish before releasing the sockThere is a race condition in vxlan that when deleting a vxlan deviceduring receiving packets, there is a possibility that the sock isreleased after getting vxlan_sock vs from sk_user_data. Then inlater vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will gotNULL pointer dereference. e.g. #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757 #1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d #2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48 #3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b #4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb #5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542 #6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62 [exception RIP: vxlan_ecn_decapsulate+0x3b] RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246 RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000 RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700 RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700 R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan] #8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507 #9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45 #10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807 #11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951 #12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde #13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b #14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139 #15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a #16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3 #17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.shFix this by waiting for all sk_user_data reader to finish beforereleasing the sock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devicesA bogus device can provide a bNumConfigurations value that exceeds theinitial value used in usb_get_configuration for allocating dev->config.This can lead to out-of-bounds accesses later, e.g. inusb_destroy_configuration.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix the infinite loop in exfat_readdir()If the file system is corrupted so that a cluster is linked toitself in the cluster chain, and there is an unused directoryentry in the cluster, 'dentry' will not be incremented, causingcondition 'dentry < max_dentries' unable to prevent an infiniteloop.This infinite loop causes s_lock not to be released, and othertasks will hang, such as exfat_sync_fs().This commit stops traversing the cluster chain when there is unuseddirectory entry in the cluster to avoid this infinite loop.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix NULL pointer dereference in l3mdev_l3_rcvWhen delete l3s ipvlan: ip link del link eth0 ipvlan1 type ipvlan mode l3sThis may cause a null pointer dereference: Call trace: ip_rcv_finish+0x48/0xd0 ip_rcv+0x5c/0x100 __netif_receive_skb_one_core+0x64/0xb0 __netif_receive_skb+0x20/0x80 process_backlog+0xb4/0x204 napi_poll+0xe8/0x294 net_rx_action+0xd8/0x22c __do_softirq+0x12c/0x354This is because l3mdev_l3_rcv() visit dev->l3mdev_ops afteripvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The processlike this: (CPU1) | (CPU2) l3mdev_l3_rcv() | check dev->priv_flags: | master = skb->dev; | | | ipvlan_l3s_unregister() | set dev->priv_flags | dev->l3mdev_ops = NULL; | visit master->l3mdev_ops |To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid journaling sb update on error if journal is destroyingPresently we always BUG_ON if trying to start a transaction on a journal markedwith JBD2_UNMOUNT, since this should never happen. However, while ltp runningstress tests, it was observed that in case of some error handling paths, it ispossible for update_super_work to start a transaction after the journal isdestroyed eg:(umount)ext4_kill_sb kill_block_super generic_shutdown_super sync_filesystem /* commits all txns */ evict_inodes /* might start a new txn */ ext4_put_super flush_work(&sbi->s_sb_upd_work) /* flush the workqueue */ jbd2_journal_destroy journal_kill_thread journal->j_flags |= JBD2_UNMOUNT; jbd2_journal_commit_transaction jbd2_journal_get_descriptor_buffer jbd2_journal_bmap ext4_journal_bmap ext4_map_blocks ... ext4_inode_error ext4_handle_error schedule_work(&sbi->s_sb_upd_work) /* work queue kicks in */ update_super_work jbd2_journal_start start_this_handle BUG_ON(journal->j_flags & JBD2_UNMOUNT)Hence, introduce a new mount flag to indicate journal is destroying and only doa journaled (and deferred) update of sb if this flag is not set. Otherwise, justfallback to an un-journaled commit.Further, in the journal destroy path, we have the following sequence: 1. Set mount flag indicating journal is destroying 2. force a commit and wait for it 3. flush pending sb updatesThis sequence is important as it ensures that, after this point, there is no sbupdate that might be journaled so it is safe to update the sb outside thejournal. (To avoid race discussed in 2d01ddc86606)Also, we don't need a similar check in ext4_grp_locked_error since it is onlycalled from mballoc and AFAICT it would be always valid to schedule work here.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: Fix deadlock when using NCM gadgetThe cdns3 driver has the same NCM deadlock as fixed in cdnsp by commit58f2fcb3a845 ("usb: cdnsp: Fix deadlock issue during using NCM gadget").Under PREEMPT_RT the deadlock can be readily triggered by heavy networktraffic, for example using "iperf --bidir" over NCM ethernet link.The deadlock occurs because the threaded interrupt handler getspreempted by a softirq, but both are protected by the same spinlock.Prevent deadlock by disabling softirq during threaded irq handler.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queueWhen the task management thread processes reply queues while the resetthread resets them, the task management thread accesses an invalid queue ID(0xFFFF), set by the reset thread, which points to unallocated memory,causing a crash.Add flag 'io_admin_reset_sync' to synchronize access between the reset,I/O, and admin threads. Before a reset, the reset handler sets this flag toblock I/O and admin processing threads. If any thread bypasses the initialcheck, the reset thread waits up to 10 seconds for processing to finish. Ifthe wait exceeds 10 seconds, the controller is marked as unrecoverable.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: mctrl_gpio: split disable_ms into sync and no_sync APIsThe following splat has been observed on a SAMA5D27 platform usingatmel_serial:BUG: sleeping function called from invalid context at kernel/irq/manage.c:738in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 27, name: kworker/u5:0preempt_count: 1, expected: 0INFO: lockdep is turned off.irq event stamp: 0hardirqs last enabled at (0): [<00000000>] 0x0hardirqs last disabled at (0): [] copy_process+0x1c4c/0x7becsoftirqs last enabled at (0): [] copy_process+0x1ca0/0x7becsoftirqs last disabled at (0): [<00000000>] 0x0CPU: 0 UID: 0 PID: 27 Comm: kworker/u5:0 Not tainted 6.13.0-rc7+ #74Hardware name: Atmel SAMA5Workqueue: hci0 hci_power_on [bluetooth]Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x44/0x70 dump_stack_lvl from __might_resched+0x38c/0x598 __might_resched from disable_irq+0x1c/0x48 disable_irq from mctrl_gpio_disable_ms+0x74/0xc0 mctrl_gpio_disable_ms from atmel_disable_ms.part.0+0x80/0x1f4 atmel_disable_ms.part.0 from atmel_set_termios+0x764/0x11e8 atmel_set_termios from uart_change_line_settings+0x15c/0x994 uart_change_line_settings from uart_set_termios+0x2b0/0x668 uart_set_termios from tty_set_termios+0x600/0x8ec tty_set_termios from ttyport_set_flow_control+0x188/0x1e0 ttyport_set_flow_control from wilc_setup+0xd0/0x524 [hci_wilc] wilc_setup [hci_wilc] from hci_dev_open_sync+0x330/0x203c [bluetooth] hci_dev_open_sync [bluetooth] from hci_dev_do_open+0x40/0xb0 [bluetooth] hci_dev_do_open [bluetooth] from hci_power_on+0x12c/0x664 [bluetooth] hci_power_on [bluetooth] from process_one_work+0x998/0x1a38 process_one_work from worker_thread+0x6e0/0xfb4 worker_thread from kthread+0x3d4/0x484 kthread from ret_from_fork+0x14/0x28This warning is emitted when trying to toggle, at the highest level,some flow control (with serdev_device_set_flow_control) in a devicedriver. At the lowest level, the atmel_serial driver is usingserial_mctrl_gpio lib to enable/disable the corresponding IRQsaccordingly. The warning emitted by CONFIG_DEBUG_ATOMIC_SLEEP is due todisable_irq (called in mctrl_gpio_disable_ms) being possibly called insome atomic context (some tty drivers perform modem lines configurationin regions protected by port lock).Split mctrl_gpio_disable_ms into two differents APIs, a non-blocking oneand a blocking one. Replace mctrl_gpio_disable_ms calls with therelevant version depending on whether the call is protected by some portlock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: prevent BUG_ON by blocking retries on failed device resumesA cache device failing to resume due to mapping errors should not beretried, as the failure leaves a partially initialized policy object.Repeating the resume operation risks triggering BUG_ON when reloadingcache mappings into the incomplete policy object.Reproduce steps:1. create a cache metadata consisting of 512 or more cache blocks, with some mappings stored in the first array block of the mapping array. Here we use cache_restore v1.0 to build the metadata.cat <> cmeta.xml EOFdmsetup create cmeta --table "0 8192 linear /dev/sdc 0"cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2dmsetup remove cmeta2. wipe the second array block of the mapping array to simulate data degradations.mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \2>/dev/null | hexdump -e '1/8 "%u\n"')ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \2>/dev/null | hexdump -e '1/8 "%u\n"')dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock3. try bringing up the cache device. The resume is expected to fail due to the broken array block.dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc 262144"dmsetup create cache --notabledmsetup load cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"dmsetup resume cache4. try resuming the cache again. An unexpected BUG_ON is triggered while loading cache mappings.dmsetup resume cacheKernel logs:(snip)------------[ cut here ]------------kernel BUG at drivers/md/dm-cache-policy-smq.c:752!Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3RIP: 0010:smq_load_mapping+0x3e5/0x570Fix by disallowing resume operations for devices that failed theinitial attempt.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: fix race between nfsd registration and exports_procAs of now nfsd calls create_proc_exports_entry() at start of init_nfsdand cleanup by remove_proc_entry() at last of exit_nfsd.Which causes kernel OOPs if there is race between below 2 operations:(i) exportfs -r(ii) mount -t nfsd none /proc/fs/nfsdfor 5.4 kernel ARM64:CPU 1:el1_irq+0xbc/0x180arch_counter_get_cntvct+0x14/0x18running_clock+0xc/0x18preempt_count_add+0x88/0x110prep_new_page+0xb0/0x220get_page_from_freelist+0x2d8/0x1778__alloc_pages_nodemask+0x15c/0xef0__vmalloc_node_range+0x28c/0x478__vmalloc_node_flags_caller+0x8c/0xb0kvmalloc_node+0x88/0xe0nfsd_init_net+0x6c/0x108 [nfsd]ops_init+0x44/0x170register_pernet_operations+0x114/0x270register_pernet_subsys+0x34/0x50init_nfsd+0xa8/0x718 [nfsd]do_one_initcall+0x54/0x2e0CPU 2 :Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010PC is at : exports_net_open+0x50/0x68 [nfsd]Call trace:exports_net_open+0x50/0x68 [nfsd]exports_proc_open+0x2c/0x38 [nfsd]proc_reg_open+0xb8/0x198do_dentry_open+0x1c4/0x418vfs_open+0x38/0x48path_openat+0x28c/0xf18do_filp_open+0x70/0xe8do_sys_open+0x154/0x248Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu().and same is happening on latest 6.14 kernel as well:[ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty...[ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48...[ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4...[ 285.469695] Call trace:[ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P)[ 285.470488] seq_read+0xe0/0x11c[ 285.470675] proc_reg_read+0x9c/0xf0[ 285.470874] vfs_read+0xc4/0x2fc[ 285.471057] ksys_read+0x6c/0xf4[ 285.471231] __arm64_sys_read+0x1c/0x28[ 285.471428] invoke_syscall+0x44/0x100[ 285.471633] el0_svc_common.constprop.0+0x40/0xe0[ 285.471870] do_el0_svc_compat+0x1c/0x34[ 285.472073] el0_svc_compat+0x2c/0x80[ 285.472265] el0t_32_sync_handler+0x90/0x140[ 285.472473] el0t_32_sync+0x19c/0x1a0[ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3)[ 285.473422] ---[ end trace 0000000000000000 ]---It reproduced simply with below script:while [ 1 ]do/exportfs -rdone &while [ 1 ]doinsmod /nfsd.komount -t nfsd none /proc/fs/nfsdumount /proc/fs/nfsdrmmod nfsddone &So exporting interfaces to user space shall be done at last andcleanup at first place.With change there is no Kernel OOPs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330The controller has a hardware bug that can hard hang the system whendoing ATAPI DMAs without any trace of what happened. Depending on thedevice attached, it can also prevent the system from booting.In this case, the system hangs when reading the ATIP from optical mediawith cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and anOptiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4,running at UDMA/33.The issue can be reproduced by running the same command with a cygwinbuild of cdrecord on WinXP, although it requires more attempts to causeit. The hang in that case is also resolved by forcing PIO. It doesn'tappear that VIA has produced any drivers for that OS, thus no knownworkaround exists.HDDs attached to the controller do not suffer from any DMA issues.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix a null-ptr access in the cursor snooperCheck that the resource which is converted to a surface exists beforetrying to use the cursor snooper on it.vmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiersbecause some svga commands accept SVGA3D_INVALID_ID to mean "no surface",unfortunately functions that accept the actual surfaces as objects might(and in case of the cursor snooper, do not) be able to handle nullobjects. Make sure that we validate not only the identifier (via thevmw_cmd_res_check) but also check that the actual resource exists beforetrying to do something with it.Fixes unchecked null-ptr reference in the snooping code.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce()If new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0and sctp_ulpevent_make_authkey() returns 0, then the variableai_ev remains zero and the zero will be dereferencedin the sctp_ulpevent_free() function.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: Vim is an open source, command line text editor. Prior to version 9.1.1552, a path traversal issue in Vim's tar.vim plugin can allow overwriting of arbitrary files when opening specially crafted tar archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1552 contains a patch for the vulnerability.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- vim > 0-0 (version in image is 9.2.0280-150500.20.46.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix invalid prog->stats access when update_effective_progs failsSyzkaller triggers an invalid memory access issue following faultinjection in update_effective_progs. The issue can be described asfollows:__cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog---softirq start---__do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp)---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype])The reason is that fault injection caused update_effective_progs to failand then changed the original prog into dummy_bpf_prog.prog inpurge_effective_progs. Then a softirq came, and accessing the members ofdummy_bpf_prog.prog in the softirq triggers invalid mem access.To fix it, skip updating stats when stats is NULL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_writeA deadlock can occur between nfc_unregister_device() and rfkill_fop_write()due to lock ordering inversion between device_lock and rfkill_global_mutex.The problematic lock order is:Thread A (rfkill_fop_write): rfkill_fop_write() mutex_lock(&rfkill_global_mutex) rfkill_set_block() nfc_rfkill_set_block() nfc_dev_down() device_lock(&dev->dev) <- waits for device_lockThread B (nfc_unregister_device): nfc_unregister_device() device_lock(&dev->dev) rfkill_unregister() mutex_lock(&rfkill_global_mutex) <- waits for rfkill_global_mutexThis creates a classic ABBA deadlock scenario.Fix this by moving rfkill_unregister() and rfkill_destroy() outside thedevice_lock critical section. Store the rfkill pointer in a local variablebefore releasing the lock, then call rfkill_unregister() after releasingdevice_lock.This change is safe because rfkill_fop_write() holds rfkill_global_mutexwhile calling the rfkill callbacks, and rfkill_unregister() also acquiresrfkill_global_mutex before cleanup. Therefore, rfkill_unregister() willwait for any ongoing callback to complete before proceeding, anddevice_del() is only called after rfkill_unregister() returns, preventingany use-after-free.The similar lock ordering in nfc_register_device() (device_lock ->rfkill_global_mutex via rfkill_register) is safe because duringregistration the device is not yet in rfkill_list, so no concurrentrfkill operations can occur on this device.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entryEndpoint drivers use dw_pcie_ep_raise_msix_irq() to raise an MSI-Xinterrupt to the host using a writel(), which generates a PCI posted writetransaction. There's no completion for posted writes, so the writel() mayreturn before the PCI write completes. dw_pcie_ep_raise_msix_irq() alsounmaps the outbound ATU entry used for the PCI write, so the write raceswith the unmap.If the PCI write loses the race with the ATU unmap, the write may corrupthost memory or cause IOMMU errors, e.g., these when running fio with alarger queue depth against nvmet-pci-epf: arm-smmu-v3 fc900000.iommu: 0x0000010000000010 arm-smmu-v3 fc900000.iommu: 0x0000020000000000 arm-smmu-v3 fc900000.iommu: 0x000000090000f040 arm-smmu-v3 fc900000.iommu: 0x0000000000000000 arm-smmu-v3 fc900000.iommu: event: F_TRANSLATION client: 0000:01:00.0 sid: 0x100 ssid: 0x0 iova: 0x90000f040 ipa: 0x0 arm-smmu-v3 fc900000.iommu: unpriv data write s1 "Input address caused fault" stag: 0x0Flush the write by performing a readl() of the same address to ensure thatthe write has reached the destination before the ATU entry is unmapped.The same problem was solved for dw_pcie_ep_raise_msi_irq() in commit8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping"), but thereit was solved by dedicating an outbound iATU only for MSI. We can't do thesame for MSI-X because each vector can have a different msg_addr and themsg_addr may be changed while the vector is masked.[bhelgaas: commit log]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix iloc.bh leak in ext4_fc_replay_inode() error pathsDuring code review, Joseph found that ext4_fc_replay_inode() callsext4_get_fc_inode_loc() to get the inode location, which holds areference to iloc.bh that must be released via brelse().However, several error paths jump to the 'out' label withoutreleasing iloc.bh: - ext4_handle_dirty_metadata() failure - sync_dirty_buffer() failure - ext4_mark_inode_used() failure - ext4_iget() failureFix this by introducing an 'out_brelse' label placed just beforethe existing 'out' label to ensure iloc.bh is always released.Additionally, make ext4_fc_replay_inode() propagate errorsproperly instead of always returning 0.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: cx25821: Fix a resource leak in cx25821_dev_setup()Add release_mem_region() if ioremap() fails to release the memoryregion obtained by cx25821_get_resources().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: u_serial: Fix race condition in TTY wakeupA race condition occurs when gs_start_io() calls either gs_start_rx() orgs_start_tx(), as those functions briefly drop the port_lock forusb_ep_queue(). This allows gs_close() and gserial_disconnect() to clearport.tty and port_usb, respectively.Use the null-safe TTY Port helper function to wake up TTY.Example CPU1: CPU2: gserial_connect() // lock gs_close() // await lock gs_start_rx() // unlock usb_ep_queue() gs_close() // lock, reset port.tty and unlock gs_start_rx() // lock tty_wakeup() // NPE
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In libexpat through 2.7.3, a crafted file with an approximate size of 2 MiB can lead to dozens of seconds of processing time.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libexpat1 > 0-0 (version in image is 2.7.1-150400.3.37.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.56.1).
-
Description: Unknown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.56.1).
-
Description: A stack overflow flaw was found when reading a BFS file system. A crafted BFS filesystem may lead to an uncontrolled loop, causing grub2 to crash.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.65.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ntb_netdev: Use dev_kfree_skb_any() in interrupt contextTX/RX callback handlers (ntb_netdev_tx_handler(),ntb_netdev_rx_handler()) can be called in interruptcontext via the DMA framework when the respectiveDMA operations have completed. As such, any callsby these routines to free skb's, should use theinterrupt context safe dev_kfree_skb_any() function.Previously, these callback handlers would call theinterrupt unsafe version of dev_kfree_skb(). This hasnot presented an issue on Intel IOAT DMA engines asthat driver utilizes tasklets rather than a hardinterrupt handler, like the AMD PTDMA DMA driver.On AMD systems, a kernel WARNING message isencountered, which is being issued fromskb_release_head_state() due to in_hardirq()being true.Besides the user visible WARNING from the kernel,the other symptom of this bug was that TCP/IP performanceacross the ntb_netdev interface was very poor, i.e.approximately an order of magnitude below what wasexpected. With the repair to use dev_kfree_skb_any(),kernel WARNINGs from skb_release_head_state() ceasedand TCP/IP performance, as measured by iperf, was onpar with expected results, approximately 20 Gb/s onAMD Milan based server. Note that this performanceis comparable with Intel based servers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: A flaw was identified in the RelaxNG parser of libxml2 related to how external schema inclusions are handled. The parser does not enforce a limit on inclusion depth when resolving nested directives. Specially crafted or overly complex schemas can cause excessive recursion during parsing. This may lead to stack exhaustion and application crashes, creating a denial-of-service risk.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libxml2-2 > 0-0 (version in image is 2.10.3-150500.5.38.1).
-
Description: Unknown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.56.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- curl > 0-0 (version in image is 8.14.1-150400.5.83.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rseq: Fix segfault on registration when rseq_cs is non-zeroThe rseq_cs field is documented as being set to 0 by user-space prior toregistration, however this is not currently enforced by the kernel. Thiscan result in a segfault on return to user-space if the value stored inthe rseq_cs field doesn't point to a valid struct rseq_cs.The correct solution to this would be to fail the rseq registration whenthe rseq_cs field is non-zero. However, some older versions of glibcwill reuse the rseq area of previous threads without clearing therseq_cs field and will also terminate the process if the rseqregistration fails in a secondary thread. This wasn't caught in testingbecause in this case the leftover rseq_cs does point to a valid structrseq_cs.What we can do is clear the rseq_cs field on registration when it'snon-zero which will prevent segfaults on registration and won't breakthe glibc versions that reuse rseq areas on thread creation.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix load-tearing on sk->sk_stamp in sock_recv_cmsgs().KCSAN found a data race in sock_recv_cmsgs() where the read accessto sk->sk_stamp needs READ_ONCE().BUG: KCSAN: data-race in packet_recvmsg / packet_recvmsgwrite (marked) to 0xffff88803c81f258 of 8 bytes by task 19171 on cpu 0: sock_write_timestamp include/net/sock.h:2670 [inline] sock_recv_cmsgs include/net/sock.h:2722 [inline] packet_recvmsg+0xb97/0xd00 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:1019 [inline] sock_recvmsg+0x11a/0x130 net/socket.c:1040 sock_read_iter+0x176/0x220 net/socket.c:1118 call_read_iter include/linux/fs.h:1845 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x5e0/0x630 fs/read_write.c:470 ksys_read+0x163/0x1a0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x41/0x50 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdcread to 0xffff88803c81f258 of 8 bytes by task 19183 on cpu 1: sock_recv_cmsgs include/net/sock.h:2721 [inline] packet_recvmsg+0xb64/0xd00 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:1019 [inline] sock_recvmsg+0x11a/0x130 net/socket.c:1040 sock_read_iter+0x176/0x220 net/socket.c:1118 call_read_iter include/linux/fs.h:1845 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x5e0/0x630 fs/read_write.c:470 ksys_read+0x163/0x1a0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x41/0x50 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdcvalue changed: 0xffffffffc4653600 -> 0x0000000000000000Reported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 19183 Comm: syz-executor.5 Not tainted 6.3.0-rc7-02330-gca6270c12e20 #2Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Don't (re)check L1 intercepts when completing userspace I/OWhen completing emulation of instruction that generated a userspace exitfor I/O, don't recheck L1 intercepts as KVM has already finished thatphase of instruction execution, i.e. has already committed to allowing L2to perform I/O. If L1 (or host userspace) modifies the I/O permissionbitmaps during the exit to userspace, KVM will treat the access as beingintercepted despite already having emulated the I/O access.Pivot on EMULTYPE_NO_DECODE to detect that KVM is completing emulation.Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (theintended "recipient") can reach the code in question. gp_interception()'suse is mutually exclusive with is_guest_mode(), andcomplete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE withEMULTYPE_SKIP.The bad behavior was detected by a syzkaller program that toggles port I/Ointerception during the userspace I/O exit, ultimately resulting in a WARNon vcpu->arch.pio.count being non-zero due to KVM no completing emulationof the I/O instruction. WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm] Modules linked in: kvm_intel kvm irqbypass CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulator_pio_in_out+0x154/0x170 [kvm] PKRU: 55555554 Call Trace: kvm_fast_pio+0xd6/0x1d0 [kvm] vmx_handle_exit+0x149/0x610 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm] kvm_vcpu_ioctl+0x244/0x8c0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0x5d/0xc60 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- openssh > 0-0 (version in image is 8.4p1-150300.3.57.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/fred: Fix system hang during S4 resume with FRED enabledUpon a wakeup from S4, the restore kernel starts and initializes theFRED MSRs as needed from its perspective. It then loads a hibernationimage, including the image kernel, and attempts to load image pagesdirectly into their original page frames used before hibernation unlessthose frames are currently in use. Once all pages are moved to theiroriginal locations, it jumps to a "trampoline" page in the image kernel.At this point, the image kernel takes control, but the FRED MSRs stillcontain values set by the restore kernel, which may differ from thoseset by the image kernel before hibernation. Therefore, the image kernelmust ensure the FRED MSRs have the same values as before hibernation.Since these values depend only on the location of the kernel text anddata, they can be recomputed from scratch.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus()If device_register() fails in tcm_loop_setup_hba_bus(), the name allocatedby dev_set_name() need be freed. As comment of device_register() says, itshould use put_device() to give up the reference in the error path. So fixthis by calling put_device(), then the name can be freed in kobject_cleanup().The 'tl_hba' will be freed in tcm_loop_release_adapter(), so it don't needgoto error label in this case.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: fix multishot accept request leaksHaving REQ_F_POLLED set doesn't guarantee that the request isexecuted as a multishot from the polling path. Fortunately for us, ifthe code thinks it's multishot issue when it's not, it can only ask toskip completion so leaking the request. Use issue_flags to markmultipoll issues.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mhi: Fix memory leak in mhi_net_dellink()MHI driver registers network device without setting theneeds_free_netdev flag, and does NOT call free_netdev() whenunregisters network device, which causes a memory leak.This patch calls free_netdev() to fix it since netdev_privis used after unregister.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/scheduler: fix fence ref countingWe leaked dependency fences when processes were beeing killed.Additional to that grab a reference to the last scheduled fence.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf trace: Really free the evsel->priv areaIn 3cb4d5e00e037c70 ("perf trace: Free syscall tp fields inevsel->priv") it only was freeing if strcmp(evsel->tp_format->system,"syscalls") returned zero, while the corresponding initialization ofevsel->priv was being performed if it was _not_ zero, i.e. if the tpsystem wasn't 'syscalls'.Just stop looking for that and free it if evsel->priv was set, whichshould be equivalent.Also use the pre-existing evsel_trace__delete() function.This resolves these leaks, detected with: $ make EXTRA_CFLAGS="-fsanitize=address" BUILD_BPF_SKEL=1 CORESIGHT=1 O=/tmp/build/perf-tools-next -C tools/perf install-bin ================================================================= ==481565==ERROR: LeakSanitizer: detected memory leaks Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097) #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966) #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307 #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333 #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458 #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480 #6 0x540e8b in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3212 #7 0x540e8b in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891 #8 0x540e8b in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156 #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323 #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377 #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421 #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537 #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097) #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966) #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307 #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333 #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458 #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480 #6 0x540dd1 in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3205 #7 0x540dd1 in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891 #8 0x540dd1 in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156 #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323 #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377 #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421 #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537 #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s). [root@quaco ~]#With this we plug all leaks with "perf trace sleep 1".
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: only decrement add_addr_accepted for MPJ reqAdding the following warning ... WARN_ON_ONCE(msk->pm.add_addr_accepted == 0)... before decrementing the add_addr_accepted counter helped to find abug when running the "remove single subflow" subtest from themptcp_join.sh selftest.Removing a 'subflow' endpoint will first trigger a RM_ADDR, then thesubflow closure. Before this patch, and upon the reception of theRM_ADDR, the other peer will then try to decrement thisadd_addr_accepted. That's not correct because the attached subflows havenot been created upon the reception of an ADD_ADDR.A way to solve that is to decrement the counter only if the attachedsubflow was an MP_JOIN to a remote id that was not 0, and initiated bythe host receiving the RM_ADDR.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: only mark 'subflow' endp as availableAdding the following warning ... WARN_ON_ONCE(msk->pm.local_addr_used == 0)... before decrementing the local_addr_used counter helped to find a bugwhen running the "remove single address" subtest from the mptcp_join.shselftests.Removing a 'signal' endpoint will trigger the removal of all subflowslinked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() withrm_type == MPTCP_MIB_RMSUBFLOW. This will decrement the local_addr_usedcounter, which is wrong in this case because this counter is linked to'subflow' endpoints, and here it is a 'signal' endpoint that is beingremoved.Now, the counter is decremented, only if the ID is being used outsideof mptcp_pm_nl_rm_addr_or_subflow(), only for 'subflow' endpoints, andif the ID is not 0 -- local_addr_used is not taking into account theseones. This marking of the ID as being available, and the decrement isdone no matter if a subflow using this ID is currently available,because the subflow could have been closed before.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nouveau/firmware: use dma non-coherent allocatorCurrently, enabling SG_DEBUG in the kernel will cause nouveau to hit aBUG() on startup, when the iommu is enabled:kernel BUG at include/linux/scatterlist.h:187!invalid opcode: 0000 [#1] PREEMPT SMP NOPTICPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30Hardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019RIP: 0010:sg_init_one+0x85/0xa0Code: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 5424 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 <0f> 0b 0f 0b0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00RSP: 0018:ffffa776017bf6a0 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffa77600d87000 RCX: 000000000000002bRDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffa77680d87000RBP: 000000000000e000 R08: 0000000000000000 R09: 0000000000000000R10: ffff98f4c46aa508 R11: 0000000000000000 R12: ffff98f4c46aa508R13: ffff98f4c46aa008 R14: ffffa77600d4a000 R15: ffffa77600d4a018FS: 00007feeb5aae980(0000) GS:ffff98f5c4dc0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f22cb9a4520 CR3: 00000001043ba000 CR4: 00000000003506f0Call Trace: ? die+0x36/0x90 ? do_trap+0xdd/0x100 ? sg_init_one+0x85/0xa0 ? do_error_trap+0x65/0x80 ? sg_init_one+0x85/0xa0 ? exc_invalid_op+0x50/0x70 ? sg_init_one+0x85/0xa0 ? asm_exc_invalid_op+0x1a/0x20 ? sg_init_one+0x85/0xa0 nvkm_firmware_ctor+0x14a/0x250 [nouveau] nvkm_falcon_fw_ctor+0x42/0x70 [nouveau] ga102_gsp_booter_ctor+0xb4/0x1a0 [nouveau] r535_gsp_oneinit+0xb3/0x15f0 [nouveau] ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? nvkm_udevice_new+0x95/0x140 [nouveau] ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? ktime_get+0x47/0xb0Fix this by using the non-coherent allocator instead, I think theremight be a better answer to this, but it involve ripping up some ofAPIs using sg lists.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: check if we need to reschedule during overflow flushIn terms of normal application usage, this list will always be empty.And if an application does overflow a bit, it'll have a few entries.However, nothing obviously prevents syzbot from running a test casethat generates a ton of overflow entries, and then flushing them cantake quite a while.Check for needing to reschedule while flushing, and drop our locks anddo so if necessary. There's no state to maintain here as overflowsalways prune from head-of-list, hence it's fine to drop and reacquirethe locks at the end of the loop.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Get rid of userspace_irqchip_in_useImproper use of userspace_irqchip_in_use led to syzbot hitting thefollowing WARN_ON() in kvm_timer_update_irq():WARNING: CPU: 0 PID: 3281 at arch/arm64/kvm/arch_timer.c:459kvm_timer_update_irq+0x21c/0x394Call trace: kvm_timer_update_irq+0x21c/0x394 arch/arm64/kvm/arch_timer.c:459 kvm_timer_vcpu_reset+0x158/0x684 arch/arm64/kvm/arch_timer.c:968 kvm_reset_vcpu+0x3b4/0x560 arch/arm64/kvm/reset.c:264 kvm_vcpu_set_target arch/arm64/kvm/arm.c:1553 [inline] kvm_arch_vcpu_ioctl_vcpu_init arch/arm64/kvm/arm.c:1573 [inline] kvm_arch_vcpu_ioctl+0x112c/0x1b3c arch/arm64/kvm/arm.c:1695 kvm_vcpu_ioctl+0x4ec/0xf74 virt/kvm/kvm_main.c:4658 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __arm64_sys_ioctl+0x108/0x184 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x78/0x1b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0xe8/0x1b0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x40/0x50 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x14c arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598The following sequence led to the scenario: - Userspace creates a VM and a vCPU. - The vCPU is initialized with KVM_ARM_VCPU_PMU_V3 during KVM_ARM_VCPU_INIT. - Without any other setup, such as vGIC or vPMU, userspace issues KVM_RUN on the vCPU. Since the vPMU is requested, but not setup, kvm_arm_pmu_v3_enable() fails in kvm_arch_vcpu_run_pid_change(). As a result, KVM_RUN returns after enabling the timer, but before incrementing 'userspace_irqchip_in_use': kvm_arch_vcpu_run_pid_change() ret = kvm_arm_pmu_v3_enable() if (!vcpu->arch.pmu.created) return -EINVAL; if (ret) return ret; [...] if (!irqchip_in_kernel(kvm)) static_branch_inc(&userspace_irqchip_in_use); - Userspace ignores the error and issues KVM_ARM_VCPU_INIT again. Since the timer is already enabled, control moves through the following flow, ultimately hitting the WARN_ON(): kvm_timer_vcpu_reset() if (timer->enabled) kvm_timer_update_irq() if (!userspace_irqchip()) ret = kvm_vgic_inject_irq() ret = vgic_lazy_init() if (unlikely(!vgic_initialized(kvm))) if (kvm->arch.vgic.vgic_model != KVM_DEV_TYPE_ARM_VGIC_V2) return -EBUSY; WARN_ON(ret);Theoretically, since userspace_irqchip_in_use's functionality can besimply replaced by '!irqchip_in_kernel()', get rid of the static keyto avoid the mismanagement, which also helps with the syzbot issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen: Fix the issue of resource not being properly released in xenbus_dev_probe()This patch fixes an issue in the function xenbus_dev_probe(). In thexenbus_dev_probe() function, within the if (err) branch at line 313, theprogram incorrectly returns err directly without releasing the resourcesallocated by err = drv->probe(dev, id). As the return value is non-zero,the upper layers assume the processing logic has failed. However, the probeoperation was performed earlier without a corresponding remove operation.Since the probe actually allocates resources, failing to perform the removeoperation could lead to problems.To fix this issue, we followed the resource release logic of thexenbus_dev_remove() function by adding a new block fail_remove before thefail_put block. After entering the branch if (err) at line 313, thefunction will use a goto statement to jump to the fail_remove block,ensuring that the previously acquired resources are correctly released,thus preventing the reference count leak.This bug was identified by an experimental static analysis tool developedby our team. The tool specializes in analyzing reference count operationsand detecting potential issues where resources are not properly managed.In this case, the tool flagged the missing release operation as apotential problem, which led to the development of this patch.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: release nexthop on device removalThe CI is hitting some aperiodic hangup at device removal time in thepmtu.sh self-test:unregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6ref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at dst_init+0x84/0x4a0 dst_alloc+0x97/0x150 ip6_dst_alloc+0x23/0x90 ip6_rt_pcpu_alloc+0x1e6/0x520 ip6_pol_route+0x56f/0x840 fib6_rule_lookup+0x334/0x630 ip6_route_output_flags+0x259/0x480 ip6_dst_lookup_tail.constprop.0+0x5c2/0x940 ip6_dst_lookup_flow+0x88/0x190 udp_tunnel6_dst_lookup+0x2a7/0x4c0 vxlan_xmit_one+0xbde/0x4a50 [vxlan] vxlan_xmit+0x9ad/0xf20 [vxlan] dev_hard_start_xmit+0x10e/0x360 __dev_queue_xmit+0xf95/0x18c0 arp_solicit+0x4a2/0xe00 neigh_probe+0xaa/0xf0While the first suspect is the dst_cache, explicitly tracking the dstowing the last device reference via probes proved such dst is held bythe nexthop in the originating fib6_info.Similar to commit f5b51fe804ec ("ipv6: route: purge exception onremoval"), we need to explicitly release the originating fib info whendisconnecting a to-be-removed device from a live ipv6 dst: move thefib6_info cleanup into ip6_dst_ifdown().Tested running:./pmtu.sh cleanup_ipv6_exceptionin a tight loop for more than 400 iterations with no spat, running anunpatched kernel I observed a splat every ~10 iterations.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: imu: kmx61: fix information leak in triggered bufferThe 'buffer' local array is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: vcnl4035: fix information leak in triggered bufferThe 'buffer' local array is used to push data to userspace from atriggered buffer, but it does not set an initial value for the singledata element, which is an u16 aligned to 8 bytes. That leaves at least4 bytes uninitialized even after writing an integer value withregmap_read().Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: pressure: zpa2326: fix information leak in triggered bufferThe 'sample' local struct is used to push data to user space from atriggered buffer, but it has a hole between the temperature and thetimestamp (u32 pressure, u16 temperature, GAP, u64 timestamp).This hole is never initialized.Initialize the struct to zero before using it to avoid pushinguninitialized information to userspace.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix memory leak in aRFS after resetFix aRFS (accelerated Receive Flow Steering) structures memory leak byadding a checker to verify if aRFS memory is already allocated whileconfiguring VSI. aRFS objects are allocated in two cases:- as part of VSI initialization (at probe), and- as part of reset handlingHowever, VSI reconfiguration executed during reset involves memoryallocation one more time, without prior releasing already allocatedresources. This led to the memory leak with the following signature:[root@os-delivery ~]# cat /sys/kernel/debug/kmemleakunreferenced object 0xff3c1ca7252e6000 (size 8192): comm "kworker/0:0", pid 8, jiffies 4296833052 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [] __kmalloc_cache_noprof+0x275/0x340 [] ice_init_arfs+0x3a/0xe0 [ice] [] ice_vsi_cfg_def+0x607/0x850 [ice] [] ice_vsi_setup+0x5b/0x130 [ice] [] ice_init+0x1c1/0x460 [ice] [] ice_probe+0x2af/0x520 [ice] [] local_pci_probe+0x43/0xa0 [] work_for_cpu_fn+0x13/0x20 [] process_one_work+0x179/0x390 [] worker_thread+0x239/0x340 [] kthread+0xcc/0x100 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30 ...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: remove wrong sb->s_sequence checkJournal emptiness is not determined by sb->s_sequence == 0 but rather bysb->s_start == 0 (which is set a few lines above). Furthermore 0 is avalid transaction ID so the check can spuriously trigger. Remove theinvalid WARN_ON.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:page_pool: avoid infinite loop to schedule delayed workerWe noticed the kworker in page_pool_release_retry() was wakenup repeatedly and infinitely in production because of thebuggy driver causing the inflight less than 0 and warningus in page_pool_inflight()[1].Since the inflight value goes negative, it means we shouldnot expect the whole page_pool to get back to work normally.This patch mitigates the adverse effect by not reschedulingthe kworker when detecting the inflight negative inpage_pool_release_retry().[1][Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------[Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages...[Mon Feb 10 20:36:11 2025] Call Trace:[Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70[Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370[Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0[Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140[Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370[Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40[Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40[Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]---Note: before this patch, the above calltrace would flood thedmesg due to repeated reschedule of release_dw kworker.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: lan743x: Fix memleak issue when GSO enabledAlways map the `skb` to the LS descriptor. Previously skb wasmapped to EXT descriptor when the number of fragments is zero withGSO enabled. Mapping the skb to EXT descriptor prevents it frombeing freed, leading to a memory leak
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/brokenA SCO connection without the proper voice_setting can causethe controller to lock up.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Reject %p% format string in bprintf-like helpersstatic const char fmt[] = "%p%"; bpf_trace_printk(fmt, sizeof(fmt));The above BPF program isn't rejected and causes a kernel warning atruntime: Please remove unsupported %\x00 in format string WARNING: CPU: 1 PID: 7244 at lib/vsprintf.c:2680 format_decode+0x49c/0x5d0This happens because bpf_bprintf_prepare skips over the second %,detected as punctuation, while processing %p. This patch fixes it bynot skipping over punctuation. %\x00 is then processed in the nextiteration and rejected.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: Add a upper bound on max_vclockssyzbot reported WARNING in max_vclocks_store.This occurs when the argument max is too large for kcalloc to handle.Extend the guard to guard against values that are too large forkcalloc
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/kexec: Enable SMT before waking offline CPUsIf SMT is disabled or a partial SMT state is enabled, when a new kernelimage is loaded for kexec, on reboot the following warning is observed:kexec: Waking offline cpu 228.WARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc[snip] NIP kexec_prepare_cpus+0x1b0/0x1bc LR kexec_prepare_cpus+0x1a0/0x1bc Call Trace: kexec_prepare_cpus+0x1a0/0x1bc (unreliable) default_machine_kexec+0x160/0x19c machine_kexec+0x80/0x88 kernel_kexec+0xd0/0x118 __do_sys_reboot+0x210/0x2c4 system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ecThis occurs as add_cpu() fails due to cpu_bootable() returning false forCPUs that fail the cpu_smt_thread_allowed() check or non primarythreads if SMT is disabled.Fix the issue by enabling SMT and resetting the number of SMT threads tothe number of threads per core, before attempting to wake up all presentCPUs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: pegasus: fix memory leak in update_eth_regs_async()When asynchronously writing to the device registers and if usb_submit_urb()fail, the code fail to release allocated to this point resources.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rtw89: ser: fix CAM leaks occurring in L2 resetThe CAM, meaning address CAM and bssid CAM here, will get leaks duringSER (system error recover) L2 reset process and ieee80211_restart_hw()which is called by L2 reset process eventually.The normal flow would be like-> add interface (acquire 1)-> enter ips (release 1)-> leave ips (acquire 1)-> connection (occupy 1) <(A) 1 leak after L2 reset if non-sec connection>The ieee80211_restart_hw() flow (under connection)-> ieee80211 reconfig-> add interface (acquire 1)-> leave ips (acquire 1)-> connection (occupy (A) + 2) <(B) 1 more leak>Originally, CAM is released before HW restart only if connection is undersecurity. Now, release CAM whatever connection it is to fix leak in (A).OTOH, check if CAM is already valid to avoid acquiring multiple times tofix (B).Besides, if AP mode, release address CAM of all stations before HW restart.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sfp: fix memory leak in sfp_probe()sfp_probe() allocates a memory chunk from sfp with sfp_alloc(). Whendevm_add_action() fails, sfp is not freed, which leads to a memory leak.We should use devm_add_action_or_reset() instead of devm_add_action().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tipc: fix possible refcount leak in tipc_sk_create()Free sk in case tipc_sk_insert() fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix refcount bug in sk_psock_get (2)Syzkaller reports refcount bug as follows:------------[ cut here ]------------refcount_t: saturated; leaking memory.WARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19Modules linked in:CPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g7e062cda7d90 #0 __refcount_add_not_zero include/linux/refcount.h:163 [inline] __refcount_inc_not_zero include/linux/refcount.h:227 [inline] refcount_inc_not_zero include/linux/refcount.h:245 [inline] sk_psock_get+0x3bc/0x410 include/linux/skmsg.h:439 tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091 tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983 tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057 tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659 tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682 sk_backlog_rcv include/net/sock.h:1061 [inline] __release_sock+0x134/0x3b0 net/core/sock.c:2849 release_sock+0x54/0x1b0 net/core/sock.c:3404 inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909 __sys_shutdown_sock net/socket.c:2331 [inline] __sys_shutdown_sock net/socket.c:2325 [inline] __sys_shutdown+0xf1/0x1b0 net/socket.c:2343 __do_sys_shutdown net/socket.c:2351 [inline] __se_sys_shutdown net/socket.c:2349 [inline] __x64_sys_shutdown+0x50/0x70 net/socket.c:2349 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 During SMC fallback process in connect syscall, kernel willreplaces TCP with SMC. In order to forward wakeupsmc socket waitqueue after fallback, kernel will setsclcsk->sk_user_data to origin smc socket insmc_fback_replace_callbacks().Later, in shutdown syscall, kernel will callssk_psock_get(), which treats the clcsk->sk_user_dataas psock type, triggering the refcnt warning.So, the root cause is that smc and psock, both will usesk_user_data field. So they will mismatch this fieldeasily.This patch solves it by using another bit(defined asSK_USER_DATA_PSOCK) in PTRMASK, to mark whethersk_user_data points to a psock object or not.This patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e("net, sk_msg: Clear sk_user_data pointer on clone if tagged").For there will possibly be more flags in the sk_user_data field,this patch also refactor sk_user_data flags code to be more genericto improve its maintainability.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl: Fix a memory leak in an error handling pathA bitmap_zalloc() must be balanced by a corresponding bitmap_free() in theerror handling path of afu_allocate_irqs().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: hisilicon/hpre - fix resource leak in remove processIn hpre_remove(), when the disable operation of qm sriov failed,the following logic should continue to be executed to release theremaining resources that have been allocated, instead of returningdirectly, otherwise there will be resource leakage.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/i10nm: fix refcount leak in pci_get_dev_wrapper()As the comment of pci_get_domain_bus_and_slot() says, it returnsa PCI device with refcount incremented, so it doesn't need tocall an extra pci_dev_get() in pci_get_dev_wrapper(), and the PCIdevice needs to be put in the error path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: fix possible memory leak in stmmac_dvr_probe()The bitmap_free() should be called to free priv->af_xdp_zc_qpswhen create_singlethread_workqueue() fails, otherwise there willbe a memory leak, so we add the err path error_wq_init to fix it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: ov5648: Free V4L2 fwnode data on unbindThe V4L2 fwnode data structure doesn't get freed on unbind, which leads toa memleak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: fix memory leak in nsim_bus_dev_new()If device_register() failed in nsim_bus_dev_new(), the value of referencein nsim_bus_dev->dev is 1. obj->name in nsim_bus_dev->dev will not bereleased.unreferenced object 0xffff88810352c480 (size 16): comm "echo", pid 5691, jiffies 4294945921 (age 133.270s) hex dump (first 16 bytes): 6e 65 74 64 65 76 73 69 6d 31 00 00 00 00 00 00 netdevsim1...... backtrace: [<000000005e2e5e26>] __kmalloc_node_track_caller+0x3a/0xb0 [<0000000094ca4fc8>] kvasprintf+0xc3/0x160 [<00000000aad09bcc>] kvasprintf_const+0x55/0x180 [<000000009bac868d>] kobject_set_name_vargs+0x56/0x150 [<000000007c1a5d70>] dev_set_name+0xbb/0xf0 [<00000000ad0d126b>] device_add+0x1f8/0x1cb0 [<00000000c222ae24>] new_device_store+0x3b6/0x5e0 [<0000000043593421>] bus_attr_store+0x72/0xa0 [<00000000cbb1833a>] sysfs_kf_write+0x106/0x160 [<00000000d0dedb8a>] kernfs_fop_write_iter+0x3a8/0x5a0 [<00000000770b66e2>] vfs_write+0x8f0/0xc80 [<0000000078bb39be>] ksys_write+0x106/0x210 [<00000000005e55a4>] do_syscall_64+0x35/0x80 [<00000000eaa40bbc>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume()There is a memory leaks problem reported by kmemleak:unreferenced object 0xffff888102007a00 (size 128): comm "ubirsvol", pid 32090, jiffies 4298464136 (age 2361.231s) hex dump (first 32 bytes):ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace:[] __kmalloc+0x4d/0x150[] ubi_eba_create_table+0x76/0x170 [ubi][] ubi_resize_volume+0x1be/0xbc0 [ubi][] ubi_cdev_ioctl+0x701/0x1850 [ubi][] __x64_sys_ioctl+0x11d/0x170[] do_syscall_64+0x35/0x80[] entry_SYSCALL_64_after_hwframe+0x46/0xb0This is due to a mismatch between create and destroy interfaces, andin detail that "new_eba_tbl" created by ubi_eba_create_table() butdestroyed by kfree(), while will causing "new_eba_tbl->entries" notfreed.Fix it by replacing kfree(new_eba_tbl) withubi_eba_destroy_table(new_eba_tbl)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpu: host1x: Fix memory leak of device namesThe device names allocated by dev_set_name() need be freedbefore module unloading, but they can not be freed becausethe kobject's refcount which was set in device_initialize()has not be decreased to 0.As comment of device_add() says, if it fails, use onlyput_device() drop the refcount, then the name will befreed in kobejct_cleanup().device_del() and put_device() can be replaced withdevice_unregister(), so call it to unregister the addedsuccessfully devices, and just call put_device() to thenot added device.Add a release() function to device to avoid null release()function WARNING in device_release(), it's empty, becausethe context devices are freed together inhost1x_memory_context_list_free().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw88: Fix memory leak in rtw88_usbKmemleak shows the following leak arising from routine in the usbprobe routine:unreferenced object 0xffff895cb29bba00 (size 512): comm "(udev-worker)", pid 534, jiffies 4294903932 (age 102751.088s) hex dump (first 32 bytes): 77 30 30 30 00 00 00 00 02 2f 2d 2b 30 00 00 00 w000...../-+0... 02 00 2a 28 00 00 00 00 ff 55 ff ff ff 00 00 00 ..*(.....U...... backtrace: [] kmalloc_trace+0x26/0x90 [] rtw_usb_probe+0x2f1/0x680 [rtw_usb] [] usb_probe_interface+0xdd/0x2e0 [usbcore] [] really_probe+0x18e/0x3d0 [] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xbf/0x1b0 [] bus_for_each_dev+0x70/0xc0 [] bus_add_driver+0x10e/0x210 [] driver_register+0x55/0xf0 [] usb_register_driver+0x88/0x140 [usbcore] [] do_one_initcall+0x43/0x210 [] do_init_module+0x4a/0x200 [] __do_sys_finit_module+0xac/0x120 [] do_syscall_64+0x56/0x80 [] entry_SYSCALL_64_after_hwframe+0x46/0xb0The leak was verified to be real by unloading the driver, which resultedin a dangling pointer to the allocation.The allocated memory is freed in rtw_usb_intf_deinit().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (xgene) Fix ioremap and memremap leakSmatch reports:drivers/hwmon/xgene-hwmon.c:757 xgene_hwmon_probe() warn:'ctx->pcc_comm_addr' from ioremap() not released on line: 757.This is because in drivers/hwmon/xgene-hwmon.c:701 xgene_hwmon_probe(),ioremap and memremap is not released, which may cause a leak.To fix this, ioremap and memremap is modified to devm_ioremap anddevm_memremap.[groeck: Fixed formatting and subject]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tun: Fix memory leak for detached NAPI queue.syzkaller reported [0] memory leaks of sk and skb related to the TUNdevice with no repro, but we can reproduce it easily with: struct ifreq ifr = {} int fd_tun, fd_tmp; char buf[4] = {}; fd_tun = openat(AT_FDCWD, "/dev/net/tun", O_WRONLY, 0); ifr.ifr_flags = IFF_TUN | IFF_NAPI | IFF_MULTI_QUEUE; ioctl(fd_tun, TUNSETIFF, &ifr); ifr.ifr_flags = IFF_DETACH_QUEUE; ioctl(fd_tun, TUNSETQUEUE, &ifr); fd_tmp = socket(AF_PACKET, SOCK_PACKET, 0); ifr.ifr_flags = IFF_UP; ioctl(fd_tmp, SIOCSIFFLAGS, &ifr); write(fd_tun, buf, sizeof(buf)); close(fd_tun);If we enable NAPI and multi-queue on a TUN device, we can put skb intotfile->sk.sk_write_queue after the queue is detached. We should preventit by checking tfile->detached before queuing skb.Note this must be done under tfile->sk.sk_write_queue.lock because write()and ioctl(IFF_DETACH_QUEUE) can run concurrently. Otherwise, there wouldbe a small race window: write() ioctl(IFF_DETACH_QUEUE) `- tun_get_user `- __tun_detach |- if (tfile->detached) |- tun_disable_queue | `-> false | `- tfile->detached = tun | `- tun_queue_purge |- spin_lock_bh(&queue->lock) `- __skb_queue_tail(queue, skb)Another solution is to call tun_queue_purge() when closing andreattaching the detached queue, but it could paper over anotherproblems. Also, we do the same kind of test for IFF_NAPI_FRAGS.[0]:unreferenced object 0xffff88801edbc800 (size 2048): comm "syz-executor.1", pid 33269, jiffies 4295743834 (age 18.756s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<000000008c16ea3d>] __do_kmalloc_node mm/slab_common.c:965 [inline] [<000000008c16ea3d>] __kmalloc+0x4a/0x130 mm/slab_common.c:979 [<000000003addde56>] kmalloc include/linux/slab.h:563 [inline] [<000000003addde56>] sk_prot_alloc+0xef/0x1b0 net/core/sock.c:2035 [<000000003e20621f>] sk_alloc+0x36/0x2f0 net/core/sock.c:2088 [<0000000028e43843>] tun_chr_open+0x3d/0x190 drivers/net/tun.c:3438 [<000000001b0f1f28>] misc_open+0x1a6/0x1f0 drivers/char/misc.c:165 [<000000004376f706>] chrdev_open+0x111/0x300 fs/char_dev.c:414 [<00000000614d379f>] do_dentry_open+0x2f9/0x750 fs/open.c:920 [<000000008eb24774>] do_open fs/namei.c:3636 [inline] [<000000008eb24774>] path_openat+0x143f/0x1a30 fs/namei.c:3791 [<00000000955077b5>] do_filp_open+0xce/0x1c0 fs/namei.c:3818 [<00000000b78973b0>] do_sys_openat2+0xf0/0x260 fs/open.c:1356 [<00000000057be699>] do_sys_open fs/open.c:1372 [inline] [<00000000057be699>] __do_sys_openat fs/open.c:1388 [inline] [<00000000057be699>] __se_sys_openat fs/open.c:1383 [inline] [<00000000057be699>] __x64_sys_openat+0x83/0xf0 fs/open.c:1383 [<00000000a7d2182d>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<00000000a7d2182d>] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80 [<000000004cc4e8c4>] entry_SYSCALL_64_after_hwframe+0x72/0xdcunreferenced object 0xffff88802f671700 (size 240): comm "syz-executor.1", pid 33269, jiffies 4295743854 (age 18.736s) hex dump (first 32 bytes): 68 c9 db 1e 80 88 ff ff 68 c9 db 1e 80 88 ff ff h.......h....... 00 c0 7b 2f 80 88 ff ff 00 c8 db 1e 80 88 ff ff ..{/............ backtrace: [<00000000e9d9fdb6>] __alloc_skb+0x223/0x250 net/core/skbuff.c:644 [<000000002c3e4e0b>] alloc_skb include/linux/skbuff.h:1288 [inline] [<000000002c3e4e0b>] alloc_skb_with_frags+0x6f/0x350 net/core/skbuff.c:6378 [<00000000825f98d7>] sock_alloc_send_pskb+0x3ac/0x3e0 net/core/sock.c:2729 [<00000000e9eb3df3>] tun_alloc_skb drivers/net/tun.c:1529 [inline] [<---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: cls_u32: Undo tcf_bind_filter if u32_replace_hw_knodeWhen u32_replace_hw_knode fails, we need to undo the tcf_bind_filteroperation done at u32_set_parms.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: isotp: check CAN address family in isotp_bind()Add missing check to block non-AF_CAN binds.Syzbot created some code which matched the right sockaddr struct sizebut used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address familyfield:bind$xdp(r2, &(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2}, 0x10) ^^^^This has no funtional impact but the userspace should be notified aboutthe wrong address family field content.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: handle case when repair happens with dev-replace[BUG]There is a bug report that a BUG_ON() in btrfs_repair_io_failure()(originally repair_io_failure() in v6.0 kernel) got triggered whenreplacing a unreliable disk: BTRFS warning (device sda1): csum failed root 257 ino 2397453 off 39624704 csum 0xb0d18c75 expected csum 0x4dae9c5e mirror 3 kernel BUG at fs/btrfs/extent_io.c:2380! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 9 PID: 3614331 Comm: kworker/u257:2 Tainted: G OE 6.0.0-5-amd64 #1 Debian 6.0.10-2 Hardware name: Micro-Star International Co., Ltd. MS-7C60/TRX40 PRO WIFI (MS-7C60), BIOS 2.70 07/01/2021 Workqueue: btrfs-endio btrfs_end_bio_work [btrfs] RIP: 0010:repair_io_failure+0x24a/0x260 [btrfs] Call Trace: clean_io_failure+0x14d/0x180 [btrfs] end_bio_extent_readpage+0x412/0x6e0 [btrfs] ? __switch_to+0x106/0x420 process_one_work+0x1c7/0x380 worker_thread+0x4d/0x380 ? rescuer_thread+0x3a0/0x3a0 kthread+0xe9/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30[CAUSE]Before the BUG_ON(), we got some read errors from the replace targetfirst, note the mirror number (3, which is beyond RAID1 duplication,thus it's read from the replace target device).Then at the BUG_ON() location, we are trying to writeback the repairedsectors back the failed device.The check looks like this: ret = btrfs_map_block(fs_info, BTRFS_MAP_WRITE, logical, &map_length, &bioc, mirror_num); if (ret) goto out_counter_dec; BUG_ON(mirror_num != bioc->mirror_num);But inside btrfs_map_block(), we can modify bioc->mirror_num especiallyfor dev-replace: if (dev_replace_is_ongoing && mirror_num == map->num_stripes + 1 && !need_full_stripe(op) && dev_replace->tgtdev != NULL) { ret = get_extra_mirror_from_replace(fs_info, logical, *length, dev_replace->srcdev->devid, &mirror_num, &physical_to_patch_in_first_stripe); patch_the_first_stripe_for_dev_replace = 1; }Thus if we're repairing the replace target device, we're going totrigger that BUG_ON().But in reality, the read failure from the replace target device may bethat, our replace hasn't reached the range we're reading, thus we'rereading garbage, but with replace running, the range would be properlyfilled later.Thus in that case, we don't need to do anything but let the replaceroutine to handle it.[FIX]Instead of a BUG_ON(), just skip the repair if we're repairing thedevice replace target device.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal()The buffer in the loop should be released under the exception path,otherwise there may be a memory leak here.To mitigate this, free the buffer when allegro_alloc_buffer fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dccp: Fix memory leak in dccp_feat_change_recvIf dccp_feat_push_confirm() fails after new value for SP feature was acceptedwithout reconciliation ('entry == NULL' branch), memory allocated for that valuewith dccp_feat_clone_sp_val() is never freed.Here is the kmemleak stack for this:unreferenced object 0xffff88801d4ab488 (size 8): comm "syz-executor310", pid 1127, jiffies 4295085598 (age 41.666s) hex dump (first 8 bytes): 01 b4 4a 1d 80 88 ff ff ..J..... backtrace: [<00000000db7cabfe>] kmemdup+0x23/0x50 mm/util.c:128 [<0000000019b38405>] kmemdup include/linux/string.h:465 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline] [<0000000019b38405>] dccp_feat_change_recv net/dccp/feat.c:1145 [inline] [<0000000019b38405>] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416 [<00000000b1f6d94a>] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125 [<0000000030d7b621>] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650 [<000000001f74c72e>] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688 [<00000000a6c24128>] sk_backlog_rcv include/net/sock.h:1041 [inline] [<00000000a6c24128>] __release_sock+0x139/0x3b0 net/core/sock.c:2570 [<00000000cf1f3a53>] release_sock+0x54/0x1b0 net/core/sock.c:3111 [<000000008422fa23>] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline] [<000000008422fa23>] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696 [<0000000015b6f64d>] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735 [<0000000010122488>] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865 [<00000000b4b70023>] __sys_connect+0x165/0x1a0 net/socket.c:1882 [<00000000f4cb3815>] __do_sys_connect net/socket.c:1892 [inline] [<00000000f4cb3815>] __se_sys_connect net/socket.c:1889 [inline] [<00000000f4cb3815>] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889 [<00000000e7b1e839>] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 [<0000000055e91434>] entry_SYSCALL_64_after_hwframe+0x67/0xd1Clean up the allocated memory in case of dccp_feat_push_confirm() failureand bail out with an error reset code.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRLCurrently tagged_addr_ctrl_set() doesn't initialize the temporary 'ctrl'variable, and a SETREGSET call with a length of zero will leave thisuninitialized. Consequently tagged_addr_ctrl_set() will consume anarbitrary value, potentially leaking up to 64 bits of memory from thekernel stack. The read is limited to a specific slot on the stack, andthe issue does not provide a write mechanism.As set_tagged_addr_ctrl() only accepts values where bits [63:4] zero andrejects other values, a partial SETREGSET attempt will randomly succeedor fail depending on the value of the uninitialized value, and theexposure is significantly limited.Fix this by initializing the temporary value before copying the regsetfrom userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existingvalue of the tagged address ctrl will be retained.The NT_ARM_TAGGED_ADDR_CTRL regset is only visible in theuser_aarch64_view used by a native AArch64 task to manipulate anothernative AArch64 task. As get_tagged_addr_ctrl() only returns an errorvalue when called for a compat task, tagged_addr_ctrl_get() andtagged_addr_ctrl_set() should never observe an error value fromget_tagged_addr_ctrl(). Add a WARN_ON_ONCE() to both to indicate thatsuch an error would be unexpected, and error handlnig is not missing ineither case.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: adc: rockchip_saradc: fix information leak in triggered bufferThe 'data' local struct is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the struct to zero before using it to avoid pushinguninitialized information to userspace.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: handle a symlink read error correctlyPatch series "Convert ocfs2 to use folios".Mark did a conversion of ocfs2 to use folios and sent it to me as agiant patch for review ;-)So I've redone it as individual patches, and credited Mark for the patcheswhere his code is substantially the same. It's not a bad way to do it;his patch had some bugs and my patches had some bugs. Hopefully all ourbugs were different from each other. And hopefully Mark likes all thechanges I made to his code!This patch (of 23):If we can't read the buffer, be sure to unlock the page before returning.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: pcap_ether_aton() is an auxiliary function in libpcap, it takes a string argument and returns a fixed-size allocated buffer. The string argument must be a well-formed MAC-48 address in one of the supported formats, but this requirement has been poorly documented. If an application calls the function with an argument that deviates from the expected format, the function can read data beyond the end of the provided string and write data beyond the end of the allocated buffer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libpcap1 > 0-0 (version in image is 1.10.1-150400.3.9.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (drivetemp) Fix driver producing garbage data when SCSI errors occurscsi_execute_cmd() function can return both negative (linux codes) andpositive (scsi_cmnd result field) error codes.Currently the driver just passes error codes of scsi_execute_cmd() tohwmon core, which is incorrect because hwmon only checks for negativeerror codes. This leads to hwmon reporting uninitialized data touserspace in case of SCSI errors (for example if the disk drive wasdisconnected).This patch checks scsi_execute_cmd() output and returns -EIO if it'serror code is positive.[groeck: Avoid inline variable declaration for portability]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Ensure job pointer is set to NULL after job completionAfter a job completes, the corresponding pointer in the device mustbe set to NULL. Failing to do so triggers a warning when unloadingthe driver, as it appears the job is still active. To prevent this,assign the job pointer to NULL after completing the job, indicatingthe job has finished.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: rose: lock the socket in rose_bind()syzbot reported a soft lockup in rose_loopback_timer(),with a repro calling bind() from multiple threads.rose_bind() must lock the socket to avoid this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: A vulnerability has been found in Hercules Augeas 1.14.1 and classified as problematic. This vulnerability affects the function re_case_expand of the file src/fa.c. The manipulation of the argument re leads to null pointer dereference. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libaugeas0 > 0-0 (version in image is 1.12.0-150400.3.8.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:openvswitch: Fix unsafe attribute parsing in output_userspace()This patch replaces the manual Netlink attribute iteration inoutput_userspace() with nla_for_each_nested(), which ensures that onlywell-formed attributes are processed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: disable napi on driver removalA warning on driver removal started occurring after commit 9dd05df8403b("net: warn if NAPI instance wasn't shut down"). Disable tx napi beforedeleting it in mt76_dma_cleanup(). WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100 CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy) Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024 RIP: 0010:__netif_napi_del_locked+0xf0/0x100 Call Trace: mt76_dma_cleanup+0x54/0x2f0 [mt76] mt7921_pci_remove+0xd5/0x190 [mt7921e] pci_device_remove+0x47/0xc0 device_release_driver_internal+0x19e/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x2e/0xb0 __do_sys_delete_module.isra.0+0x197/0x2e0 do_syscall_64+0x7b/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7eTested with mt7921e but the same pattern can be actually applied to othermt76 drivers calling mt76_dma_cleanup() during removal. Tx napi is enabledin their *_dma_init() functions and only toggled off and on again insidetheir suspend/resume/reset paths. So it should be okay to disable txnapi in such a generic way.Found by Linux Verification Center (linuxtesting.org).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: spinand: fix memory leak of ECC engine confMemory allocated for the ECC engine conf is not released during spinandcleanup. Below kmemleak trace is seen for this memory leak:unreferenced object 0xffffff80064f00e0 (size 8): comm "swapper/0", pid 1, jiffies 4294937458 hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace (crc 0): kmemleak_alloc+0x30/0x40 __kmalloc_cache_noprof+0x208/0x3c0 spinand_ondie_ecc_init_ctx+0x114/0x200 nand_ecc_init_ctx+0x70/0xa8 nanddev_ecc_engine_init+0xec/0x27c spinand_probe+0xa2c/0x1620 spi_mem_probe+0x130/0x21c spi_probe+0xf0/0x170 really_probe+0x17c/0x6e8 __driver_probe_device+0x17c/0x21c driver_probe_device+0x58/0x180 __device_attach_driver+0x15c/0x1f8 bus_for_each_drv+0xec/0x150 __device_attach+0x188/0x24c device_initial_probe+0x10/0x20 bus_probe_device+0x11c/0x160Fix the leak by calling nanddev_ecc_engine_cleanup() insidespinand_cleanup().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm: Fix another leak in the submit error pathput_unused_fd() doesn't free the installed file, if we've already donefd_install(). So we need to also free the sync_file.Patchwork: https://patchwork.freedesktop.org/patch/653583/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Set DMA unmap len correctly for XDP_REDIRECTWhen transmitting an XDP_REDIRECT packet, call dma_unmap_len_set()with the proper length instead of 0. This bug triggers this warningon a system with IOMMU enabled:WARNING: CPU: 36 PID: 0 at drivers/iommu/dma-iommu.c:842 __iommu_dma_unmap+0x159/0x170RIP: 0010:__iommu_dma_unmap+0x159/0x170Code: a8 00 00 00 00 48 c7 45 b0 00 00 00 00 48 c7 45 c8 00 00 00 00 48 c7 45 a0 ff ff ff ff 4c 89 45b8 4c 89 45 c0 e9 77 ff ff ff <0f> 0b e9 60 ff ff ff e8 8b bf 6a 00 66 66 2e 0f 1f 84 00 00 00 00RSP: 0018:ff22d31181150c88 EFLAGS: 00010206RAX: 0000000000002000 RBX: 00000000e13a0000 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ff22d31181150cf0 R08: ff22d31181150ca8 R09: 0000000000000000R10: 0000000000000000 R11: ff22d311d36c9d80 R12: 0000000000001000R13: ff13544d10645010 R14: ff22d31181150c90 R15: ff13544d0b2bac00FS: 0000000000000000(0000) GS:ff13550908a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005be909dacff8 CR3: 0008000173408003 CR4: 0000000000f71ef0PKRU: 55555554Call Trace:? show_regs+0x6d/0x80? __warn+0x89/0x160? __iommu_dma_unmap+0x159/0x170? report_bug+0x17e/0x1b0? handle_bug+0x46/0x90? exc_invalid_op+0x18/0x80? asm_exc_invalid_op+0x1b/0x20? __iommu_dma_unmap+0x159/0x170? __iommu_dma_unmap+0xb3/0x170iommu_dma_unmap_page+0x4f/0x100dma_unmap_page_attrs+0x52/0x220? srso_alias_return_thunk+0x5/0xfbef5? xdp_return_frame+0x2e/0xd0bnxt_tx_int_xdp+0xdf/0x440 [bnxt_en]__bnxt_poll_work_done+0x81/0x1e0 [bnxt_en]bnxt_poll+0xd3/0x1e0 [bnxt_en]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too largeThe handling of the `COMEDI_INSNLIST` ioctl allocates a kernel buffer tohold the array of `struct comedi_insn`, getting the length from the`n_insns` member of the `struct comedi_insnlist` supplied by the user.The allocation will fail with a WARNING and a stack dump if it is toolarge.Avoid that by failing with an `-EINVAL` error if the supplied `n_insns`value is unreasonable.Define the limit on the `n_insns` value in the `MAX_INSNS` macro. Setthis to the same value as `MAX_SAMPLES` (65536), which is the maximumallowed sum of the values of the member `n` in the array of `structcomedi_insn`, and sensible comedi instructions will have an `n` of atleast 1.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: pnv_php: Fix surprise plug detection and recoveryThe existing PowerNV hotplug code did not handle surprise plug eventscorrectly, leading to a complete failure of the hotplug system after deviceremoval and a required reboot to detect new devices.This comes down to two issues: 1) When a device is surprise removed, often the bridge upstream port will cause a PE freeze on the PHB. If this freeze is not cleared, the MSI interrupts from the bridge hotplug notification logic will not be received by the kernel, stalling all plug events on all slots associated with the PE. 2) When a device is removed from a slot, regardless of surprise or programmatic removal, the associated PHB/PE ls left frozen. If this freeze is not cleared via a fundamental reset, skiboot is unable to clear the freeze and cannot retrain / rescan the slot. This also requires a reboot to clear the freeze and redetect the device in the slot.Issue the appropriate unfreeze and rescan commands on hotplug events,and don't oops on hotplug if pci_bus_to_OF_node() returns NULL.[bhelgaas: tidy comments]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: increase scan_ies_len for S1GCurrently the S1G capability element is not taken into accountfor the scan_ies_len, which leads to a buffer length validationfailure in ieee80211_prep_hw_scan() and subsequent WARN in__ieee80211_start_scan(). This prevents hw scanning from functioning.To fix ensure we accommodate for the S1G capability length.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Fix refcount leak for cifs_sb_tlinkFix three refcount inconsistency issues related to `cifs_sb_tlink`.Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to becalled after successful calls to `cifs_sb_tlink()`. Three calls fail toupdate refcount accordingly, leading to possible resource leaks.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfs: Don't leak disconnected dentries on umountWhen user calls open_by_handle_at() on some inode that is not cached, wewill create disconnected dentry for it. If such dentry is a directory,exportfs_decode_fh_raw() will then try to connect this dentry to thedentry tree through reconnect_path(). It may happen for various reasons(such as corrupted fs or race with rename) that the call tolookup_one_unlocked() in reconnect_one() will fail to find the dentry weare trying to reconnect and instead create a new dentry under theparent. Now this dentry will not be marked as disconnected although theparent still may well be disconnected (at least in case thisinconsistency happened because the fs is corrupted and .. doesn't pointto the real parent directory). This creates inconsistency indisconnected flags but AFAICS it was mostly harmless. At least untilcommit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon")which removed adding of most disconnected dentries to sb->s_anon list.Thus after this commit cleanup of disconnected dentries implicitelyrelies on the fact that dput() will immediately reclaim such dentries.However when some leaf dentry isn't marked as disconnected, as in thescenario described above, the reclaim doesn't happen and the dentriesare "leaked". Memory reclaim can eventually reclaim them but otherwisethey stay in memory and if umount comes first, we hit infamous "Busyinodes after unmount" bug. Make sure all dentries created under adisconnected parent are marked as disconnected as well.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicastsyzbot reported WARNING in rtl8150_start_xmit/usb_submit_urb.This is the sequence of events that leads to the warning:rtl8150_start_xmit() { netif_stop_queue(); usb_submit_urb(dev->tx_urb);}rtl8150_set_multicast() { netif_stop_queue(); netif_wake_queue(); <-- wakes up TX queue before URB is done}rtl8150_start_xmit() { netif_stop_queue(); usb_submit_urb(dev->tx_urb); <-- double submission}rtl8150_set_multicast being the ndo_set_rx_mode callback should not becalling netif_stop_queue and notif_start_queue as these handleTX queue synchronization.The net core function dev_set_rx_mode handles the synchronizationfor rtl8150_set_multicast making it safe to remove these locks.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: hugetlb: avoid soft lockup when mprotect to large memory areaWhen calling mprotect() to a large hugetlb memory area in our customer'sworkload (~300GB hugetlb memory), soft lockup was observed:watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916]CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : mte_clear_page_tags+0x14/0x24lr : mte_sync_tags+0x1c0/0x240sp : ffff80003150bb80x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2cx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000Call trace: mte_clear_page_tags+0x14/0x24 set_huge_pte_at+0x25c/0x280 hugetlb_change_protection+0x220/0x430 change_protection+0x5c/0x8c mprotect_fixup+0x10c/0x294 do_mprotect_pkey.constprop.0+0x2e0/0x3d4 __arm64_sys_mprotect+0x24/0x44 invoke_syscall+0x50/0x160 el0_svc_common+0x48/0x144 do_el0_svc+0x30/0xe0 el0_svc+0x30/0xf0 el0t_64_sync_handler+0xc4/0x148 el0t_64_sync+0x1a4/0x1a8Soft lockup is not triggered with THP or base page because there iscond_resched() called for each PMD size.Although the soft lockup was triggered by MTE, it should be not MTEspecific. The other processing which takes long time in the loop maytrigger soft lockup too.So add cond_resched() for hugetlb to avoid soft lockup.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen/events: Return -EEXIST for bound VIRQsChange find_virq() to return -EEXIST when a VIRQ is bound to adifferent CPU than the one passed in. With that, remove the BUG_ON()from bind_virq_to_irq() to propogate the error upwards.Some VIRQs are per-cpu, but others are per-domain or global. Those mustbe bound to CPU0 and can then migrate elsewhere. The lookup forper-domain and global will probably fail when migrated off CPU 0,especially when the current CPU is tracked. This now returns -EEXISTinstead of BUG_ON().A second call to bind a per-domain or global VIRQ is not expected, butmake it non-fatal to avoid trying to look up the irq, since we don'tknow which per_cpu(virq_to_irq) it will be in.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: asix: validate PHY address before useThe ASIX driver reads the PHY address from the USB device viaasix_read_phy_addr(). A malicious or faulty device can return aninvalid address (>= PHY_MAX_ADDR), which causes a warning inmdiobus_get_phy(): addr 207 out of range WARNING: drivers/net/phy/mdio_bus.c:76Validate the PHY address in asix_read_phy_addr() and remove thenow-redundant check in ax88172a.c.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Do not register unsupported perf eventsSynthetic events currently do not have a function to register perf events.This leads to calling the tracepoint register functions with a NULLfunction pointer which triggers: ------------[ cut here ]------------ WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272 Modules linked in: kvm_intel kvm irqbypass CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:tracepoint_add_func+0x357/0x370 Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000 RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8 RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780 R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78 FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0 Call Trace: tracepoint_probe_register+0x5d/0x90 synth_event_reg+0x3c/0x60 perf_trace_event_init+0x204/0x340 perf_trace_init+0x85/0xd0 perf_tp_event_init+0x2e/0x50 perf_try_init_event+0x6f/0x230 ? perf_event_alloc+0x4bb/0xdc0 perf_event_alloc+0x65a/0xdc0 __se_sys_perf_event_open+0x290/0x9f0 do_syscall_64+0x93/0x7b0 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? trace_hardirqs_off+0x53/0xc0 entry_SYSCALL_64_after_hwframe+0x76/0x7eInstead, have the code return -ENODEV, which doesn't warn and has perferror out with: # perf record -e synthetic:futex_waitError:The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait)."dmesg | grep -i perf" may provide additional information.Ideally perf should support synthetic events, but for now just fix thewarning. The support can come later.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: avoid chain re-validation if possibleHamza Mahfooz reports cpu soft lock-ups innft_chain_validate(): watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547][..] RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables][..] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_table_validate+0x6b/0xb0 [nf_tables] nf_tables_validate+0x8b/0xa0 [nf_tables] nf_tables_commit+0x1df/0x1eb0 [nf_tables][..]Currently nf_tables will traverse the entire table (chain graph), startingfrom the entry points (base chains), exploring all possible paths(chain jumps). But there are cases where we could avoid revalidation.Consider:1 input -> j2 -> j32 input -> j2 -> j33 input -> j1 -> j2 -> j3Then the second rule does not need to revalidate j2, and, by extension j3,because this was already checked during validation of the first rule.We need to validate it only for rule 3.This is needed because chain loop detection also ensures we do not exceedthe jump stack: Just because we know that j2 is cycle free, its last jumpmight now exceed the allowed stack size. We also need to update allreachable chains with the new largest observed call depth.Care has to be taken to revalidate even if the chain depth won't be anissue: chain validation also ensures that expressions are not called frominvalid base chains. For example, the masquerade expression can only becalled from NAT postrouting base chains.Therefore we also need to keep record of the base chain context (type,hooknum) and revalidate if the chain becomes reachable from a differenthook location.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:audit: add fchmodat2() to change attributes classfchmodat2(), introduced in version 6.6 is currently not in the changeattribute class of audit. Calling fchmodat2() to change a fileattribute in the same fashion than chmod() or fchmodat() will bypassaudit rules such as:-w /tmp/test -p rwa -k test_rwaThe current patch adds fchmodat2() to the change attributes class.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: The 'zipfile' module would not check the validity of the ZIP64 End ofCentral Directory (EOCD) Locator record offset value would not be used tolocate the ZIP64 EOCD record, instead the ZIP64 EOCD record would beassumed to be the previous record in the ZIP archive. This could be abusedto create ZIP archives that are handled differently by the 'zipfile' modulecompared to other ZIP implementations.Remediation maintains this behavior, but checks that the offset specifiedin the ZIP64 EOCD Locator record matches the expected value.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.1).
-
Description: A vulnerability was found in libxml2 up to 2.14.5. It has been declared as problematic. This vulnerability affects the function xmlParseSGMLCatalog of the component xmlcatalog. The manipulation leads to uncontrolled recursion. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. The code maintainer explains, that "[t]he issue can only be triggered with untrusted SGML catalogs and it makes absolutely no sense to use untrusted catalogs. I also doubt that anyone is still using SGML catalogs at all."
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libxml2-2 > 0-0 (version in image is 2.10.3-150500.5.38.1).
-
Description: A vulnerability was determined in jqlang jq up to 1.6. Impacted is the function run_jq_tests of the file jq_test.c of the component JSON Parser. Executing manipulation can lead to reachable assertion. The attack requires local access. The exploit has been publicly disclosed and may be utilized. Other versions might be affected as well.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libssh-config > 0-0 (version in image is 0.9.8-150400.3.17.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libxml2-2 > 0-0 (version in image is 2.10.3-150500.5.38.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: omap-dma: fix dma_pool resource leak in error pathsThe dma_pool created by dma_pool_create() is not destroyed whendma_async_device_register() or of_dma_controller_register() fails,causing a resource leak in the probe error paths.Add dma_pool_destroy() in both error paths to properly release theallocated dma_pool resource.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fou: Don't allow 0 for FOU_ATTR_IPPROTO.fou_udp_recv() has the same problem mentioned in the previouspatch.If FOU_ATTR_IPPROTO is set to 0, skb is not freed byfou_udp_recv() nor "resubmit"-ted in ip_protocol_deliver_rcu().Let's forbid 0 for FOU_ATTR_IPPROTO.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:audit: add missing syscalls to read classThe "at" variant of getxattr() and listxattr() are missing from theaudit read class. Calling getxattrat() or listxattrat() on a file toread its extended attributes will bypass audit rules such as:-w /tmp/test -p rwa -k test_rwaThe current patch adds missing syscalls to the audit read class.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: Fix kernel stack leak in irdma_create_user_ah()struct irdma_create_ah_resp { // 8 bytes, no padding __u32 ah_id; // offset 0 - SET (uresp.ah_id = ah->sc_ah.ah_info.ah_idx) __u8 rsvd[4]; // offset 4 - NEVER SET <- LEAK};rsvd[4]: 4 bytes of stack memory leaked unconditionally. Only ah_id is assigned before ib_respond_udata().The reserved members of the structure were not zeroed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: atmel-sha204a - Fix OOM ->tfm_count leakIf memory allocation fails, decrement ->tfm_count to avoid blockingfuture reads.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix memory leaks in ceph_mdsc_build_path()Add __putname() calls to error code paths that did not free the "path"pointer obtained by __getname(). If ownership of this pointer is notpassed to the caller via path_info.path, the function must free itbefore returning.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: When doing SSH-based transfers using either SCP or SFTP, and asked to dopublic key authentication, curl would wrongly still ask and authenticate usinga locally running SSH agent.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- curl > 0-0 (version in image is 8.14.1-150400.5.83.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libssh-config > 0-0 (version in image is 0.9.8-150400.3.17.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- openssh > 0-0 (version in image is 8.4p1-150300.3.57.1).
-
Description: When combined with specific software sequences, AMD CPUs may transiently execute non-canonical loads and store using only the lower 48 address bits potentially resulting in data leakage.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In libxml2 before 2.13.8 and 2.14.x before 2.14.2, xmlSchemaIDCFillNodeTables in xmlschemas.c has a heap-based buffer under-read. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libxml2-2 > 0-0 (version in image is 2.10.3-150500.5.38.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libexpat1 > 0-0 (version in image is 2.7.1-150400.3.37.1).
-
Description: A vulnerability classified as problematic was found in vim up to 9.1.1096. This vulnerability affects unknown code of the file src/main.c. The manipulation of the argument --log leads to memory corruption. It is possible to launch the attack on the local host. Upgrading to version 9.1.1097 is able to address this issue. The patch is identified as c5654b84480822817bb7b69ebc97c174c91185e9. It is recommended to upgrade the affected component.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- vim > 0-0 (version in image is 9.2.0280-150500.20.46.1).
-
Description: In GnuPG before 2.5.5, if a user chooses to import a certificate with certain crafted subkey data that lacks a valid backsig or that has incorrect usage flags, the user loses the ability to verify signatures made from certain other signing keys, aka a "verification DoS."
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- gpg2 > 0-0 (version in image is 2.2.27-150300.3.19.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igb: Fix igb_down hung on surprise removalIn a setup where a Thunderbolt hub connects to Ethernet and a displaythrough USB Type-C, users may experience a hung task timeout when theyremove the cable between the PC and the Thunderbolt hub.This is because the igb_down function is called multiple times whenthe Thunderbolt hub is unplugged. For example, the igb_io_error_detectedtriggers the first call, and the igb_remove triggers the second call.The second call to igb_down will block at napi_synchronize.Here's the call trace: __schedule+0x3b0/0xddb ? __mod_timer+0x164/0x5d3 schedule+0x44/0xa8 schedule_timeout+0xb2/0x2a4 ? run_local_timers+0x4e/0x4e msleep+0x31/0x38 igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4] __igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4] igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4] __dev_close_many+0x95/0xec dev_close_many+0x6e/0x103 unregister_netdevice_many+0x105/0x5b1 unregister_netdevice_queue+0xc2/0x10d unregister_netdev+0x1c/0x23 igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4] pci_device_remove+0x3f/0x9c device_release_driver_internal+0xfe/0x1b4 pci_stop_bus_device+0x5b/0x7f pci_stop_bus_device+0x30/0x7f pci_stop_bus_device+0x30/0x7f pci_stop_and_remove_bus_device+0x12/0x19 pciehp_unconfigure_device+0x76/0xe9 pciehp_disable_slot+0x6e/0x131 pciehp_handle_presence_or_link_change+0x7a/0x3f7 pciehp_ist+0xbe/0x194 irq_thread_fn+0x22/0x4d ? irq_thread+0x1fd/0x1fd irq_thread+0x17b/0x1fd ? irq_forced_thread_fn+0x5f/0x5f kthread+0x142/0x153 ? __irq_get_irqchip_state+0x46/0x46 ? kthread_associate_blkcg+0x71/0x71 ret_from_fork+0x1f/0x30In this case, igb_io_error_detected detaches the network interfaceand requests a PCIE slot reset, however, the PCIE reset callback isnot being invoked and thus the Ethernet connection breaks down.As the PCIE error in this case is a non-fatal one, requesting aslot reset can be avoided.This patch fixes the task hung issue and preserves Ethernetconnection by ignoring non-fatal PCIE errors.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: x_tables: fix percpu counter block leak on error path when creating new netnsHere is the stack where we allocate percpu counter block: +-< __alloc_percpu +-< xt_percpu_counter_alloc +-< find_check_entry # {arp,ip,ip6}_tables.c +-< translate_tableAnd it can be leaked on this code path: +-> ip6t_register_table +-> translate_table # allocates percpu counter block +-> xt_register_table # failsthere is no freeing of the counter block on xt_register_table fail.Note: xt_percpu_counter_free should be called to free it like we do indo_replace through cleanup_entry helper (or in __ip6t_unregister_table).Probability of hitting this error path is low AFAICS (xt_register_tablecan only return ENOMEM here, as it is not replacing anything, as we arecreating new netns, and it is hard to imagine that all previousallocations succeeded and after that one in xt_register_table failed).But it's worth fixing even the rare leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: Initialize cfid->tcon before performing network opsAvoid leaking a tcon ref when a lease break races with opening thecached directory. Processing the leak break might take a reference tothe tcon in cached_dir_lease_break() and then fail to release the ref incached_dir_offload_close, since cfid->tcon is still NULL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sound/virtio: Fix cancel_sync warnings on uninitialized work_structsBetty reported hitting the following warning:[ 8.709131][ T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182...[ 8.713282][ T221] Call trace:[ 8.713365][ T221] __flush_work+0x8d0/0x914[ 8.713468][ T221] __cancel_work_sync+0xac/0xfc[ 8.713570][ T221] cancel_work_sync+0x24/0x34[ 8.713667][ T221] virtsnd_remove+0xa8/0xf8 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276][ 8.713868][ T221] virtsnd_probe+0x48c/0x664 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276][ 8.714035][ T221] virtio_dev_probe+0x28c/0x390[ 8.714139][ T221] really_probe+0x1bc/0x4c8...It seems we're hitting the error path in virtsnd_probe(), whichtriggers a virtsnd_remove() which iterates over the substreamscalling cancel_work_sync() on the elapsed_period work_struct.Looking at the code, from earlier in:virtsnd_probe()->virtsnd_build_devs()->virtsnd_pcm_parse_cfg()We set snd->nsubstreams, allocate the snd->substreams, and ifwe then hit an error on the info allocation or something invirtsnd_ctl_query_info() fails, we will exit without havinginitialized the elapsed_period work_struct.When that error path unwinds we then call virtsnd_remove()which as long as the substreams array is allocated, will iteratethrough calling cancel_work_sync() on the uninitialized workstruct hitting this warning.Takashi Iwai suggested this fix, which initializes the substreamsstructure right after allocation, so that if we hit the errorpaths we avoid trying to cleanup uninitialized data.Note: I have not yet managed to reproduce the issue myself, sothis patch has had limited testing.Feedback or thoughts would be appreciated!
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: st: Fix array overflow in st_setup()Change the array size to follow parms size instead of a fixed value.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config()Fix a memory leak in gpi_peripheral_config() where the original memorypointed to by gchan->config could be lost if krealloc() fails.The issue occurs when:1. gchan->config points to previously allocated memory2. krealloc() fails and returns NULL3. The function directly assigns NULL to gchan->config, losing the reference to the original memory4. The original memory becomes unreachable and cannot be freedFix this by using a temporary variable to hold the krealloc() resultand only updating gchan->config when the allocation succeeds.Found via static analysis and code review.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Reinject transport-mode packets through workqueueThe following warning is displayed when the tcp6-multi-diffip11 stresstest case of the LTP test suite is tested:watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ns-tcpserver:48198]CPU: 0 PID: 48198 Comm: ns-tcpserver Kdump: loaded Not tainted 6.0.0-rc6+ #39Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : des3_ede_encrypt+0x27c/0x460 [libdes]lr : 0x3fsp : ffff80000ceaa1b0x29: ffff80000ceaa1b0 x28: ffff0000df056100 x27: ffff0000e51e5280x26: ffff80004df75030 x25: ffff0000e51e4600 x24: 000000000000003bx23: 0000000000802080 x22: 000000000000003d x21: 0000000000000038x20: 0000000080000020 x19: 000000000000000a x18: 0000000000000033x17: ffff0000e51e4780 x16: ffff80004e2d1448 x15: ffff80004e2d1248x14: ffff0000e51e4680 x13: ffff80004e2d1348 x12: ffff80004e2d1548x11: ffff80004e2d1848 x10: ffff80004e2d1648 x9 : ffff80004e2d1748x8 : ffff80004e2d1948 x7 : 000000000bcaf83d x6 : 000000000000001bx5 : ffff80004e2d1048 x4 : 00000000761bf3bf x3 : 000000007f1dd0a3x2 : ffff0000e51e4780 x1 : ffff0000e3b9a2f8 x0 : 00000000db44e872Call trace: des3_ede_encrypt+0x27c/0x460 [libdes] crypto_des3_ede_encrypt+0x1c/0x30 [des_generic] crypto_cbc_encrypt+0x148/0x190 crypto_skcipher_encrypt+0x2c/0x40 crypto_authenc_encrypt+0xc8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp6_output_tail+0x1c8/0x5d0 [esp6] esp6_output+0x120/0x278 [esp6] xfrm_output_one+0x458/0x4ec xfrm_output_resume+0x6c/0x1f0 xfrm_output+0xac/0x4ac __xfrm6_output+0x130/0x270 xfrm6_output+0x60/0xec ip6_xmit+0x2ec/0x5bc inet6_csk_xmit+0xbc/0x10c __tcp_transmit_skb+0x460/0x8c0 tcp_write_xmit+0x348/0x890 __tcp_push_pending_frames+0x44/0x110 tcp_rcv_established+0x3c8/0x720 tcp_v6_do_rcv+0xdc/0x4a0 tcp_v6_rcv+0xc24/0xcb0 ip6_protocol_deliver_rcu+0xf0/0x574 ip6_input_finish+0x48/0x7c ip6_input+0x48/0xc0 ip6_rcv_finish+0x80/0x9c xfrm_trans_reinject+0xb0/0xf4 tasklet_action_common.constprop.0+0xf8/0x134 tasklet_action+0x30/0x3c __do_softirq+0x128/0x368 do_softirq+0xb4/0xc0 __local_bh_enable_ip+0xb0/0xb4 put_cpu_fpsimd_context+0x40/0x70 kernel_neon_end+0x20/0x40 sha1_base_do_update.constprop.0.isra.0+0x11c/0x140 [sha1_ce] sha1_ce_finup+0x94/0x110 [sha1_ce] crypto_shash_finup+0x34/0xc0 hmac_finup+0x48/0xe0 crypto_shash_finup+0x34/0xc0 shash_digest_unaligned+0x74/0x90 crypto_shash_digest+0x4c/0x9c shash_ahash_digest+0xc8/0xf0 shash_async_digest+0x28/0x34 crypto_ahash_digest+0x48/0xcc crypto_authenc_genicv+0x88/0xcc [authenc] crypto_authenc_encrypt+0xd8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp6_output_tail+0x1c8/0x5d0 [esp6] esp6_output+0x120/0x278 [esp6] xfrm_output_one+0x458/0x4ec xfrm_output_resume+0x6c/0x1f0 xfrm_output+0xac/0x4ac __xfrm6_output+0x130/0x270 xfrm6_output+0x60/0xec ip6_xmit+0x2ec/0x5bc inet6_csk_xmit+0xbc/0x10c __tcp_transmit_skb+0x460/0x8c0 tcp_write_xmit+0x348/0x890 __tcp_push_pending_frames+0x44/0x110 tcp_push+0xb4/0x14c tcp_sendmsg_locked+0x71c/0xb64 tcp_sendmsg+0x40/0x6c inet6_sendmsg+0x4c/0x80 sock_sendmsg+0x5c/0x6c __sys_sendto+0x128/0x15c __arm64_sys_sendto+0x30/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x170/0x194 do_el0_svc+0x38/0x4c el0_svc+0x28/0xe0 el0t_64_sync_handler+0xbc/0x13c el0t_64_sync+0x180/0x184Get softirq info by bcc tool:./softirqs -NT 10Tracing soft irq event time... Hit Ctrl-C to end.15:34:34SOFTIRQ TOTAL_nsecsblock 158990timer 20030920sched 46577080net_rx 676746820tasklet 990606765015:34:45SOFTIRQ TOTAL_nsecsblock 86100sched 38849790net_rx ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xsk: fix refcount underflow in error pathFix a refcount underflow problem reported by syzbot that can happenwhen a system is running out of memory. If xp_alloc_tx_descs() fails,and it can only fail due to not having enough memory, then the errorpath is triggered. In this error path, the refcount of the pool isdecremented as it has incremented before. However, the reference tothe pool in the socket was not nulled. This means that when the socketis closed later, the socket teardown logic will think that there is apool attached to the socket and try to decrease the refcount again,leading to a refcount underflow.I chose this fix as it involved adding just a single line. Anotheroption would have been to move xp_get_pool() and the assignment ofxs->pool to after the if-statement and using xs_umem->pool instead ofxs->pool in the whole if-statement resulting in somewhat simpler code,but this would have led to much more churn in the code base perhapsmaking it harder to backport.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:devlink: report devlink_port_type_warn source devicedevlink_port_type_warn is scheduled for port devlink and warningwhen the port type is not set. But from this warning it is not easyfound out which device (driver) has no devlink port set.[ 3709.975552] Type was not set for devlink port.[ 3709.975579] WARNING: CPU: 1 PID: 13092 at net/devlink/leftover.c:6775 devlink_port_type_warn+0x11/0x20[ 3709.993967] Modules linked in: openvswitch nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nfnetlink bluetooth rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs vhost_net vhost vhost_iotlb tap tun bridge stp llc qrtr intel_rapl_msr intel_rapl_common i10nm_edac nfit libnvdimm x86_pkg_temp_thermal mlx5_ib intel_powerclamp coretemp dell_wmi ledtrig_audio sparse_keymap ipmi_ssif kvm_intel ib_uverbs rfkill ib_core video kvm iTCO_wdt acpi_ipmi intel_vsec irqbypass ipmi_si iTCO_vendor_support dcdbas ipmi_devintf mei_me ipmi_msghandler rapl mei intel_cstate isst_if_mmio isst_if_mbox_pci dell_smbios intel_uncore isst_if_common i2c_i801 dell_wmi_descriptor wmi_bmof i2c_smbus intel_pch_thermal pcspkr acpi_power_meter xfs libcrc32c sd_mod sg nvme_tcp mgag200 i2c_algo_bit nvme_fabrics drm_shmem_helper drm_kms_helper nvme syscopyarea ahci sysfillrect sysimgblt nvme_core fb_sys_fops crct10dif_pclmul libahci mlx5_core sfc crc32_pclmul nvme_common drm[ 3709.994030] crc32c_intel mtd t10_pi mlxfw libata tg3 mdio megaraid_sas psample ghash_clmulni_intel pci_hyperv_intf wmi dm_multipath sunrpc dm_mirror dm_region_hash dm_log dm_mod be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse[ 3710.108431] CPU: 1 PID: 13092 Comm: kworker/1:1 Kdump: loaded Not tainted 5.14.0-319.el9.x86_64 #1[ 3710.108435] Hardware name: Dell Inc. PowerEdge R750/0PJ80M, BIOS 1.8.2 09/14/2022[ 3710.108437] Workqueue: events devlink_port_type_warn[ 3710.108440] RIP: 0010:devlink_port_type_warn+0x11/0x20[ 3710.108443] Code: 84 76 fe ff ff 48 c7 03 20 0e 1a ad 31 c0 e9 96 fd ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 48 c7 c7 18 24 4e ad e8 ef 71 62 ff <0f> 0b c3 cc cc cc cc 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f6 87[ 3710.108445] RSP: 0018:ff3b6d2e8b3c7e90 EFLAGS: 00010282[ 3710.108447] RAX: 0000000000000000 RBX: ff366d6580127080 RCX: 0000000000000027[ 3710.108448] RDX: 0000000000000027 RSI: 00000000ffff86de RDI: ff366d753f41f8c8[ 3710.108449] RBP: ff366d658ff5a0c0 R08: ff366d753f41f8c0 R09: ff3b6d2e8b3c7e18[ 3710.108450] R10: 0000000000000001 R11: 0000000000000023 R12: ff366d753f430600[ 3710.108451] R13: ff366d753f436900 R14: 0000000000000000 R15: ff366d753f436905[ 3710.108452] FS: 0000000000000000(0000) GS:ff366d753f400000(0000) knlGS:0000000000000000[ 3710.108453] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 3710.108454] CR2: 00007f1c57bc74e0 CR3: 000000111d26a001 CR4: 0000000000773ee0[ 3710.108456] PKRU: 55555554[ 3710.108457] Call Trace:[ 3710.108458] [ 3710.108459] process_one_work+0x1e2/0x3b0[ 3710.108466] ? rescuer_thread+0x390/0x390[ 3710.108468] worker_thread+0x50/0x3a0[ 3710.108471] ? rescuer_thread+0x390/0x390[ 3710.108473] kthread+0xdd/0x100[ 3710.108477] ? kthread_complete_and_exit+0x20/0x20[ 3710.108479] ret_from_fork+0x1f/0x30[ 3710.108485] [ 3710.108486] ---[ end trace 1b4b23cd0c65d6a0 ]---After patch:[ 402.473064] ice 0000:41:00.0: Type was not set for devlink port.[ 402.473064] ice 0000:41:00.1: Type was not set for devlink port.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()Hook "qedi_ops->common->sb_init = qed_sb_init" does not release the DMAmemory sb_virt when it fails. Add dma_free_coherent() to free it. Thisis the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATINGIn fscache_create_volume(), there is a missing memory barrier between thebit-clearing operation and the wake-up operation. This may cause asituation where, after a wake-up, the bit-clearing operation hasn't beendetected yet, leading to an indefinite wait. The triggering process is asfollows: [cookie1] [cookie2] [volume_work]fscache_perform_lookup fscache_create_volume fscache_perform_lookup fscache_create_volume fscache_create_volume_work cachefiles_acquire_volume clear_and_wake_up_bit test_and_set_bit test_and_set_bit goto maybe_wait goto no_waitIn the above process, cookie1 and cookie2 has the same volume. When cookie1enters the -no_wait- process, it will clear the bit and wake up the waitingprocess. If a barrier is missing, it may cause cookie2 to remain in the-wait- process indefinitely.In commit 3288666c7256 ("fscache: Use clear_and_wake_up_bit() infscache_create_volume_work()"), barriers were added to similar operationsin fscache_create_volume_work(), but fscache_create_volume() was missed.By combining the clear and wake operations into clear_and_wake_up_bit() tofix this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix bpf_sk_select_reuseport() memory leakAs pointed out in the original comment, lookup in sockmap can return a TCPESTABLISHED socket. Such TCP socket may have had SO_ATTACH_REUSEPORT_EBPFset before it was ESTABLISHED. In other words, a non-NULL sk_reuseport_cbdoes not imply a non-refcounted socket.Drop sk's reference in both error paths.unreferenced object 0xffff888101911800 (size 2048): comm "test_progs", pid 44109, jiffies 4297131437 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 9336483b): __kmalloc_noprof+0x3bf/0x560 __reuseport_alloc+0x1d/0x40 reuseport_alloc+0xca/0x150 reuseport_attach_prog+0x87/0x140 sk_reuseport_attach_bpf+0xc8/0x100 sk_setsockopt+0x1181/0x1990 do_sock_setsockopt+0x12b/0x160 __sys_setsockopt+0x7b/0xc0 __x64_sys_setsockopt+0x1b/0x30 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: socket: Lookup orig tuple for IPv6 SNATnf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets torestore the original 5-tuple in case of SNAT, to be able to find theright socket (if any). Then socket_match() can correctly check whetherthe socket was transparent.However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks thisconntrack lookup, making xt_socket fail to match on the socket when thepacket was SNATed. Add the same logic to nf_sk_lookup_slow_v6.IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, aspods' addresses are in the fd00::/8 ULA subnet and need to be replacedwith the node's external address. Cilium leverages Envoy to enforce L7policies, and Envoy uses transparent sockets. Cilium inserts an iptablesprerouting rule that matches on `-m socket --transparent` and redirectsthe packets to localhost, but it fails to match SNATed IPv6 packets dueto that missing conntrack lookup.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock... or we risk stealing final mntput from sync umount - raising mnt_countafter umount(2) has verified that victim is not busy, but before ithas set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't seethat it's safe to quietly undo mnt_count increment and leaves droppingthe reference to caller, where it'll be a full-blown mntput().Check under mount_lock is needed; leaving the current one done beforetaking that makes no sense - it's nowhere near common enough to botherwith.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()Update struct hid_descriptor to better reflect the mandatory andoptional parts of the HID Descriptor as per USB HID 1.11 specification.Note: the kernel currently does not parse any optional HID classdescriptors, only the mandatory report descriptor.Update all references to member element desc[0] to rpt_desc.Add test to verify bLength and bNumDescriptors values are valid.Replace the for loop with direct access to the mandatory HID classdescriptor member for the report descriptor. This eliminates thepossibility of getting an out-of-bounds fault.Add a warning message if the HID descriptor contains any unsupportedoptional HID class descriptors.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()A soft lockup warning was observed on a relative small system x86-64system with 16 GB of memory when running a debug kernel with kmemleakenabled. watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]The test system was running a workload with hot unplug happening inparallel. Then kemleak decided to disable itself due to its inability toallocate more kmemleak objects. The debug kernel has itsCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.The soft lockup happened in kmemleak_do_cleanup() when the existingkmemleak objects were being removed and deleted one-by-one in a loop via aworkqueue. In this particular case, there are at least 40,000 objectsthat need to be processed and given the slowness of a debug kernel and thefact that a raw_spinlock has to be acquired and released in__delete_object(), it could take a while to properly handle all theseobjects.As kmemleak has been disabled in this case, the object removal anddeletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edgecase that should rarely happen. So the simple solution is to callcond_resched() at periodic interval in the iteration loop to avoid softlockup.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix field-spanning memcpy warning in AH outputFix field-spanning memcpy warnings in ah6_output() andah6_output_done() where extension headers are copied to/from IPv6address fields, triggering fortify-string warnings about writes beyondthe 16-byte address fields. memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439The warnings are false positives as the extension headers areintentionally placed after the IPv6 header in memory. Fix by properlycopying addresses and extension headers separately, and introducehelper functions to avoid code duplication.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: If the value passed to os.path.expandvars() is user-controlled a performance degradation is possible when expanding environment variables.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/cm: Fix leaking the multicast GID table referenceIf the CM ID is destroyed while the CM event for multicast creating isstill queued the cancel_work_sync() will prevent the work from runningwhich also prevents destroying the ah_attr. This leaks a refcount andtriggers a WARN: GID entry ref leak for dev syz1 index 2 ref=573 WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline] WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886Destroy the ah_attr after canceling the work, it is safe to call thistwice.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- openssh > 0-0 (version in image is 8.4p1-150300.3.57.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libexpat1 > 0-0 (version in image is 2.7.1-150400.3.37.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: check error for register_netdev() on initCurrent init logic ignores the error code from register_netdev(),which will cause WARN_ON() on attempt to unregister it, if there was one,and there is no info for the user that the creation of the netdev failed.WARNING: CPU: 89 PID: 6902 at net/core/dev.c:11512 unregister_netdevice_many_notify+0x211/0x1a10...[ 3707.563641] unregister_netdev+0x1c/0x30[ 3707.563656] idpf_vport_dealloc+0x5cf/0xce0 [idpf][ 3707.563684] idpf_deinit_task+0xef/0x160 [idpf][ 3707.563712] idpf_vc_core_deinit+0x84/0x320 [idpf][ 3707.563739] idpf_remove+0xbf/0x780 [idpf][ 3707.563769] pci_device_remove+0xab/0x1e0[ 3707.563786] device_release_driver_internal+0x371/0x530[ 3707.563803] driver_detach+0xbf/0x180[ 3707.563816] bus_remove_driver+0x11b/0x2a0[ 3707.563829] pci_unregister_driver+0x2a/0x250Introduce an error check and log the vport number and error code.On removal make sure to check VPORT_REG_NETDEV flag prior to callingunregister and free on the netdev.Add local variables for idx, vport_config and netdev for readability.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scmi: Balance device refcount when destroying devicesUsing device_find_child() to lookup the proper SCMI device to destroycauses an unbalance in device refcount, since device_find_child() calls animplicit get_device(): this, in turns, inhibits the call of the providedrelease methods upon devices destruction.As a consequence, one of the structures that is not freed properly upondestruction is the internal struct device_private dev->p populated by thedrivers subsystem core.KMemleak detects this situation since loading/unloding some SCMI drivercauses related devices to be created/destroyed without calling anydevice_release method.unreferenced object 0xffff00000f583800 (size 512): comm "insmod", pid 227, jiffies 4294912190 hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff ........`6...... backtrace (crc 114e2eed): kmemleak_alloc+0xbc/0xd8 __kmalloc_cache_noprof+0x2dc/0x398 device_add+0x954/0x12d0 device_register+0x28/0x40 __scmi_device_create.part.0+0x1bc/0x380 scmi_device_create+0x2d0/0x390 scmi_create_protocol_devices+0x74/0xf8 scmi_device_request_notifier+0x1f8/0x2a8 notifier_call_chain+0x110/0x3b0 blocking_notifier_call_chain+0x70/0xb0 scmi_driver_register+0x350/0x7f0 0xffff80000a3b3038 do_one_initcall+0x12c/0x730 do_init_module+0x1dc/0x640 load_module+0x4b20/0x5b70 init_module_from_file+0xec/0x158$ ./scripts/faddr2line ./vmlinux device_add+0x954/0x12d0device_add+0x954/0x12d0:kmalloc_noprof at include/linux/slab.h:901(inlined by) kzalloc_noprof at include/linux/slab.h:1037(inlined by) device_private_init at drivers/base/core.c:3510(inlined by) device_add at drivers/base/core.c:3561Balance device refcount by issuing a put_device() on devices found viadevice_find_child().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: reject on-disk inodes of an unsupported typeSyzbot has reported the following BUG:kernel BUG at fs/inode.c:668!Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014RIP: 0010:clear_inode+0x168/0x190Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7fRSP: 0018:ffffc900027dfae8 EFLAGS: 00010093RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80FS: 0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? clear_inode+0x168/0x190 ? do_error_trap+0x1dc/0x2c0 ? clear_inode+0x168/0x190 ? __pfx_do_error_trap+0x10/0x10 ? report_bug+0x3cd/0x500 ? handle_invalid_op+0x34/0x40 ? clear_inode+0x168/0x190 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? clear_inode+0x57/0x190 ? clear_inode+0x167/0x190 ? clear_inode+0x168/0x190 ? clear_inode+0x167/0x190 jfs_evict_inode+0xb5/0x440 ? __pfx_jfs_evict_inode+0x10/0x10 evict+0x4ea/0x9b0 ? __pfx_evict+0x10/0x10 ? iput+0x713/0xa50 txUpdateMap+0x931/0xb10 ? __pfx_txUpdateMap+0x10/0x10 jfs_lazycommit+0x49a/0xb80 ? _raw_spin_unlock_irqrestore+0x8f/0x140 ? lockdep_hardirqs_on+0x99/0x150 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_default_wake_function+0x10/0x10 ? __kthread_parkme+0x169/0x1d0 ? __pfx_jfs_lazycommit+0x10/0x10 kthread+0x2f2/0x390 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4d/0x80 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 This happens when 'clear_inode()' makes an attempt to finalize an underlyingJFS inode of unknown type. According to JFS layout description fromhttps://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to15 are reserved for future extensions and should not be encountered on a validfilesystem. So add an extra check for valid inode type in 'copy_from_dinode()'.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: fix debug actions orderThe order of actions taken for debug was implemented incorrectly.Now we implemented the dump split and do the FW reset only in themiddle of the dump (rather than the FW killing itself on error.)As a result, some of the actions taken when applying the configwill now crash the device, so we need to fix the order.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:coresight: Fix memory leak in acpi_buffer->pointerThere are memory leaks reported by kmemleak:...unreferenced object 0xffff00213c141000 (size 1024): comm "systemd-udevd", pid 2123, jiffies 4294909467 (age 6062.160s) hex dump (first 32 bytes): 04 00 00 00 02 00 00 00 18 10 14 3c 21 00 ff ff ...........] __kmem_cache_alloc_node+0x2f8/0x348 [<00000000b0fc7ceb>] __kmalloc+0x58/0x108 [<0000000064ff4695>] acpi_os_allocate+0x2c/0x68 [<000000007d57d116>] acpi_ut_initialize_buffer+0x54/0xe0 [<0000000024583908>] acpi_evaluate_object+0x388/0x438 [<0000000017b2e72b>] acpi_evaluate_object_typed+0xe8/0x240 [<000000005df0eac2>] coresight_get_platform_data+0x1b4/0x988 [coresight]...The ACPI buffer memory (buf.pointer) should be freed. But the bufferis also used after returning from acpi_get_dsd_graph().Move the temporary variables buf to acpi_coresight_parse_graph(),and free it before the function return to prevent memory leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: reject unhashed sockets in bpf_sk_assignThe semantics for bpf_sk_assign are as follows: sk = some_lookup_func() bpf_sk_assign(skb, sk) bpf_sk_release(sk)That is, the sk is not consumed by bpf_sk_assign. The functiontherefore needs to make sure that sk lives long enough to beconsumed from __inet_lookup_skb. The path through the stack for aTCPv4 packet is roughly: netif_receive_skb_core: takes RCU read lock __netif_receive_skb_core: sch_handle_ingress: tcf_classify: bpf_sk_assign() deliver_ptype_list_skb: deliver_skb: ip_packet_type->func == ip_rcv: ip_rcv_core: ip_rcv_finish_core: dst_input: ip_local_deliver: ip_local_deliver_finish: ip_protocol_deliver_rcu: tcp_v4_rcv: __inet_lookup_skb: skb_steal_sockThe existing helper takes advantage of the fact that everythinghappens in the same RCU critical section: for sockets withSOCK_RCU_FREE set bpf_sk_assign never takes a reference.skb_steal_sock then checks SOCK_RCU_FREE again and does sock_putif necessary.This approach assumes that SOCK_RCU_FREE is never set on a skbetween bpf_sk_assign and skb_steal_sock, but this invariant isviolated by unhashed UDP sockets. A new UDP socket is createdin TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is onlyadded in udp_lib_get_port() which happens when a socket is bound.When bpf_sk_assign was added it wasn't possible to access unhashedUDP sockets from BPF, so this wasn't a problem. This changedin commit 0c48eefae712 ("sock_map: Lift socket state restrictionfor datagram sockets"), but the helper wasn't adjusted accordingly.The following sequence of events will therefore lead to a refcountleak:1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap.2. Pull socket out of sockmap and bpf_sk_assign it. Since SOCK_RCU_FREE is not set we increment the refcount.3. bind() or connect() the socket, setting SOCK_RCU_FREE.4. skb_steal_sock will now set refcounted = false due to SOCK_RCU_FREE.5. tcp_v4_rcv() skips sock_put().Fix the problem by rejecting unhashed sockets in bpf_sk_assign().This matches the behaviour of __inet_lookup_skb which is ultimatelythe goal of bpf_sk_assign().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- libssh-config > 0-0 (version in image is 0.9.8-150400.3.17.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid0, raid10: Don't set discard sectors for request queueIt should use disk_stack_limits to get a proper max_discard_sectorsrather than setting a value by stack drivers.And there is a bug. If all member disks are rotational devices,raid0/raid10 set max_discard_sectors. So the member devices arenot ssd/nvme, but raid0/raid10 export the wrong value. It reportswarning messages in function __blkdev_issue_discard when mkfs.xfslike this:[ 4616.022599] ------------[ cut here ]------------[ 4616.027779] WARNING: CPU: 4 PID: 99634 at block/blk-lib.c:50 __blkdev_issue_discard+0x16a/0x1a0[ 4616.140663] RIP: 0010:__blkdev_issue_discard+0x16a/0x1a0[ 4616.146601] Code: 24 4c 89 20 31 c0 e9 fe fe ff ff c1 e8 09 8d 48 ff 4c 89 f0 4c 09 e8 48 85 c1 0f 84 55 ff ff ff b8 ea ff ff ff e9 df fe ff ff <0f> 0b 48 8d 74 24 08 e8 ea d6 00 00 48 c7 c6 20 1e 89 ab 48 c7 c7[ 4616.167567] RSP: 0018:ffffaab88cbffca8 EFLAGS: 00010246[ 4616.173406] RAX: ffff9ba1f9e44678 RBX: 0000000000000000 RCX: ffff9ba1c9792080[ 4616.181376] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ba1c9792080[ 4616.189345] RBP: 0000000000000cc0 R08: ffffaab88cbffd10 R09: 0000000000000000[ 4616.197317] R10: 0000000000000012 R11: 0000000000000000 R12: 0000000000000000[ 4616.205288] R13: 0000000000400000 R14: 0000000000000cc0 R15: ffff9ba1c9792080[ 4616.213259] FS: 00007f9a5534e980(0000) GS:ffff9ba1b7c80000(0000) knlGS:0000000000000000[ 4616.222298] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 4616.228719] CR2: 000055a390a4c518 CR3: 0000000123e40006 CR4: 00000000001706e0[ 4616.236689] Call Trace:[ 4616.239428] blkdev_issue_discard+0x52/0xb0[ 4616.244108] blkdev_common_ioctl+0x43c/0xa00[ 4616.248883] blkdev_ioctl+0x116/0x280[ 4616.252977] __x64_sys_ioctl+0x8a/0xc0[ 4616.257163] do_syscall_64+0x5c/0x90[ 4616.261164] ? handle_mm_fault+0xc5/0x2a0[ 4616.265652] ? do_user_addr_fault+0x1d8/0x690[ 4616.270527] ? do_syscall_64+0x69/0x90[ 4616.274717] ? exc_page_fault+0x62/0x150[ 4616.279097] entry_SYSCALL_64_after_hwframe+0x63/0xcd[ 4616.284748] RIP: 0033:0x7f9a55398c6b
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: Fix uninit-value access of imap allocated in the diMount() functionsyzbot reports that hex_dump_to_buffer is using uninit-value:=====================================================BUG: KMSAN: uninit-value in hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171print_hex_dump+0x13d/0x3e0 lib/hexdump.c:276diFree+0x5ba/0x4350 fs/jfs/jfs_imap.c:876jfs_evict_inode+0x510/0x550 fs/jfs/inode.c:156evict+0x723/0xd10 fs/inode.c:796iput_final fs/inode.c:1946 [inline]iput+0x97b/0xdb0 fs/inode.c:1972txUpdateMap+0xf3e/0x1150 fs/jfs/jfs_txnmgr.c:2367txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]jfs_lazycommit+0x627/0x11d0 fs/jfs/jfs_txnmgr.c:2733kthread+0x6b9/0xef0 kernel/kthread.c:464ret_from_fork+0x6d/0x90 arch/x86/kernel/process.c:148ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244Uninit was created at:slab_post_alloc_hook mm/slub.c:4121 [inline]slab_alloc_node mm/slub.c:4164 [inline]__kmalloc_cache_noprof+0x8e3/0xdf0 mm/slub.c:4320kmalloc_noprof include/linux/slab.h:901 [inline]diMount+0x61/0x7f0 fs/jfs/jfs_imap.c:105jfs_mount+0xa8e/0x11d0 fs/jfs/jfs_mount.c:176jfs_fill_super+0xa47/0x17c0 fs/jfs/super.c:523get_tree_bdev_flags+0x6ec/0x910 fs/super.c:1636get_tree_bdev+0x37/0x50 fs/super.c:1659jfs_get_tree+0x34/0x40 fs/jfs/super.c:635vfs_get_tree+0xb1/0x5a0 fs/super.c:1814do_new_mount+0x71f/0x15e0 fs/namespace.c:3560path_mount+0x742/0x1f10 fs/namespace.c:3887do_mount fs/namespace.c:3900 [inline]__do_sys_mount fs/namespace.c:4111 [inline]__se_sys_mount+0x71f/0x800 fs/namespace.c:4088__x64_sys_mount+0xe4/0x150 fs/namespace.c:4088x64_sys_call+0x39bf/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:166do_syscall_x64 arch/x86/entry/common.c:52 [inline]do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83entry_SYSCALL_64_after_hwframe+0x77/0x7f=====================================================The reason is that imap is not properly initialized after memoryallocation. It will cause the snprintf() function to write uninitializeddata into linebuf within hex_dump_to_buffer().Fix this by using kzalloc instead of kmalloc to clear its content at thebeginning in diMount().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/kasan: Fix early region not updated correctlyThe shadow's page table is not updated when PTE_RPN_SHIFT is 24and PAGE_SHIFT is 12. It not only causes false positives butalso false negative as shown the following text.Fix it by bringing the logic of kasan_early_shadow_page_entry here.1. False Positive:==================================================================BUG: KASAN: vmalloc-out-of-bounds in pcpu_alloc+0x508/0xa50Write of size 16 at addr f57f3be0 by task swapper/0/1CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-12267-gdebe436e77c7 #1Call Trace:[c80d1c20] [c07fe7b8] dump_stack_lvl+0x4c/0x6c (unreliable)[c80d1c40] [c02ff668] print_address_description.constprop.0+0x88/0x300[c80d1c70] [c02ff45c] kasan_report+0x1ec/0x200[c80d1cb0] [c0300b20] kasan_check_range+0x160/0x2f0[c80d1cc0] [c03018a4] memset+0x34/0x90[c80d1ce0] [c0280108] pcpu_alloc+0x508/0xa50[c80d1d40] [c02fd7bc] __kmem_cache_create+0xfc/0x570[c80d1d70] [c0283d64] kmem_cache_create_usercopy+0x274/0x3e0[c80d1db0] [c2036580] init_sd+0xc4/0x1d0[c80d1de0] [c00044a0] do_one_initcall+0xc0/0x33c[c80d1eb0] [c2001624] kernel_init_freeable+0x2c8/0x384[c80d1ef0] [c0004b14] kernel_init+0x24/0x170[c80d1f10] [c001b26c] ret_from_kernel_thread+0x5c/0x64Memory state around the buggy address: f57f3a80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3b00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8>f57f3b80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f57f3c00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3c80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8==================================================================2. False Negative (with KASAN tests):==================================================================Before fix: ok 45 - kmalloc_double_kzfree # vmalloc_oob: EXPECTATION FAILED at lib/test_kasan.c:1039 KASAN failure expected in "((volatile char *)area)[3100]", but none occurred not ok 46 - vmalloc_oob not ok 1 - kasan==================================================================After fix: ok 1 - kasan
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:highmem: fix checks in __kmap_local_sched_{in,out}When CONFIG_DEBUG_KMAP_LOCAL is enabled __kmap_local_sched_{in,out} checkthat even slots in the tsk->kmap_ctrl.pteval are unmapped. The slots areinitialized with 0 value, but the check is done with pte_none. 0 ptehowever does not necessarily mean that pte_none will return true. e.g.on xtensa it returns false, resulting in the following runtime warnings: WARNING: CPU: 0 PID: 101 at mm/highmem.c:627 __kmap_local_sched_out+0x51/0x108 CPU: 0 PID: 101 Comm: touch Not tainted 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Call Trace: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_out+0x51/0x108 __schedule+0x71a/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7f WARNING: CPU: 0 PID: 101 at mm/highmem.c:664 __kmap_local_sched_in+0x50/0xe0 CPU: 0 PID: 101 Comm: touch Tainted: G W 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Call Trace: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_in+0x50/0xe0 finish_task_switch$isra$0+0x1ce/0x2f8 __schedule+0x86e/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7fFix it by replacing !pte_none(pteval) with pte_val(pteval) != 0.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix uninit-value in mpol_rebind_policy()mpol_set_nodemask()(mm/mempolicy.c) does not set up nodemask whenpol->mode is MPOL_LOCAL. Check pol->mode before accesspol->w.cpuset_mems_allowed in mpol_rebind_policy()(mm/mempolicy.c).BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:352 [inline]BUG: KMSAN: uninit-value in mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 mpol_rebind_policy mm/mempolicy.c:352 [inline] mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 cpuset_change_task_nodemask kernel/cgroup/cpuset.c:1711 [inline] cpuset_attach+0x787/0x15e0 kernel/cgroup/cpuset.c:2278 cgroup_migrate_execute+0x1023/0x1d20 kernel/cgroup/cgroup.c:2515 cgroup_migrate kernel/cgroup/cgroup.c:2771 [inline] cgroup_attach_task+0x540/0x8b0 kernel/cgroup/cgroup.c:2804 __cgroup1_procs_write+0x5cc/0x7a0 kernel/cgroup/cgroup-v1.c:520 cgroup1_tasks_write+0x94/0xb0 kernel/cgroup/cgroup-v1.c:539 cgroup_file_write+0x4c2/0x9e0 kernel/cgroup/cgroup.c:3852 kernfs_fop_write_iter+0x66a/0x9f0 fs/kernfs/file.c:296 call_write_iter include/linux/fs.h:2162 [inline] new_sync_write fs/read_write.c:503 [inline] vfs_write+0x1318/0x2030 fs/read_write.c:590 ksys_write+0x28b/0x510 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0xdb/0x120 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeUninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] slab_alloc mm/slub.c:3259 [inline] kmem_cache_alloc+0x902/0x11c0 mm/slub.c:3264 mpol_new mm/mempolicy.c:293 [inline] do_set_mempolicy+0x421/0xb70 mm/mempolicy.c:853 kernel_set_mempolicy mm/mempolicy.c:1504 [inline] __do_sys_set_mempolicy mm/mempolicy.c:1510 [inline] __se_sys_set_mempolicy+0x44c/0xb60 mm/mempolicy.c:1507 __x64_sys_set_mempolicy+0xd8/0x110 mm/mempolicy.c:1507 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeKMSAN: uninit-value in mpol_rebind_task (2)https://syzkaller.appspot.com/bug?id=d6eb90f952c2a5de9ea718a1b873c55cb13b59dcThis patch seems to fix below bug too.KMSAN: uninit-value in mpol_rebind_mm (2)https://syzkaller.appspot.com/bug?id=f2fecd0d7013f54ec4162f60743a2b28df40926bThe uninit-value is pol->w.cpuset_mems_allowed in mpol_rebind_policy().When syzkaller reproducer runs to the beginning of mpol_new(), mpol_new() mm/mempolicy.c do_mbind() mm/mempolicy.c kernel_mbind() mm/mempolicy.c`mode` is 1(MPOL_PREFERRED), nodes_empty(*nodes) is `true` and `flags`is 0. Then mode = MPOL_LOCAL; ... policy->mode = mode; policy->flags = flags;will be executed. So in mpol_set_nodemask(), mpol_set_nodemask() mm/mempolicy.c do_mbind() kernel_mbind()pol->mode is 4 (MPOL_LOCAL), that `nodemask` in `pol` is not initialized,which will be accessed in mpol_rebind_policy().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: add handling for RAID1C23/DUP to btrfs_reduce_alloc_profileCallers of `btrfs_reduce_alloc_profile` expect it to return exactlyone allocation profile flag, and failing to do so may ultimatelyresult in a WARN_ON and remount-ro when allocating new blocks, likethe below transaction abort on 6.1.`btrfs_reduce_alloc_profile` has two ways of determining the profile,first it checks if a conversion balance is currently running anduses the profile we're converting to. If no balance is currentlyrunning, it returns the max-redundancy profile which at least oneblock in the selected block group has.This works by simply checking each known allocation profile bit inredundancy order. However, `btrfs_reduce_alloc_profile` has not beenupdated as new flags have been added - first with the `DUP` profileand later with the RAID1C34 profiles.Because of the way it checks, if we have blocks with differentprofiles and at least one is known, that profile will be selected.However, if none are known we may return a flag set with multipleallocation profiles set.This is currently only possible when a balance from one of the threeunhandled profiles to another of the unhandled profiles is canceledafter allocating at least one block using the new profile.In that case, a transaction abort like the below will occur and thefilesystem will need to be mounted with -o skip_balance to get itmounted rw again (but the balance cannot be resumed without asimilar abort). [770.648] ------------[ cut here ]------------ [770.648] BTRFS: Transaction aborted (error -22) [770.648] WARNING: CPU: 43 PID: 1159593 at fs/btrfs/extent-tree.c:4122 find_free_extent+0x1d94/0x1e00 [btrfs] [770.648] CPU: 43 PID: 1159593 Comm: btrfs Tainted: G W 6.1.0-0.deb11.7-powerpc64le #1 Debian 6.1.20-2~bpo11+1a~test [770.648] Hardware name: T2P9D01 REV 1.00 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV [770.648] NIP: c00800000f6784fc LR: c00800000f6784f8 CTR: c000000000d746c0 [770.648] REGS: c000200089afe9a0 TRAP: 0700 Tainted: G W (6.1.0-0.deb11.7-powerpc64le Debian 6.1.20-2~bpo11+1a~test) [770.648] MSR: 9000000002029033 CR: 28848282 XER: 20040000 [770.648] CFAR: c000000000135110 IRQMASK: 0 GPR00: c00800000f6784f8 c000200089afec40 c00800000f7ea800 0000000000000026 GPR04: 00000001004820c2 c000200089afea00 c000200089afe9f8 0000000000000027 GPR08: c000200ffbfe7f98 c000000002127f90 ffffffffffffffd8 0000000026d6a6e8 GPR12: 0000000028848282 c000200fff7f3800 5deadbeef0000122 c00000002269d000 GPR16: c0002008c7797c40 c000200089afef17 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000001 c000200008bc5a98 0000000000000001 GPR24: 0000000000000000 c0000003c73088d0 c000200089afef17 c000000016d3a800 GPR28: c0000003c7308800 c00000002269d000 ffffffffffffffea 0000000000000001 [770.648] NIP [c00800000f6784fc] find_free_extent+0x1d94/0x1e00 [btrfs] [770.648] LR [c00800000f6784f8] find_free_extent+0x1d90/0x1e00 [btrfs] [770.648] Call Trace: [770.648] [c000200089afec40] [c00800000f6784f8] find_free_extent+0x1d90/0x1e00 [btrfs] (unreliable) [770.648] [c000200089afed30] [c00800000f681398] btrfs_reserve_extent+0x1a0/0x2f0 [btrfs] [770.648] [c000200089afeea0] [c00800000f681bf0] btrfs_alloc_tree_block+0x108/0x670 [btrfs] [770.648] [c000200089afeff0] [c00800000f66bd68] __btrfs_cow_block+0x170/0x850 [btrfs] [770.648] [c000200089aff100] [c00800000f66c58c] btrfs_cow_block+0x144/0x288 [btrfs] [770.648] [c000200089aff1b0] [c00800000f67113c] btrfs_search_slot+0x6b4/0xcb0 [btrfs] [770.648] [c000200089aff2a0] [c00800000f679f60] lookup_inline_extent_backref+0x128/0x7c0 [btrfs] [770.648] [c000200089aff3b0] [c00800000f67b338] lookup_extent_backref+0x70/0x190 [btrfs] [770.648] [c000200089aff470] [c00800000f67b54c] __btrfs_free_extent+0xf4/0x1490 [btrfs] [770.648] [---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_ffa: Fix FFA device names for logical partitionsEach physical partition can provide multiple services each with UUID.Each such service can be presented as logical partition with a uniquecombination of VM ID and UUID. The number of distinct UUID in a systemwill be less than or equal to the number of logical partitions.However, currently it fails to register more than one logical partitionor service within a physical partition as the device name contains onlyVM ID while both VM ID and UUID are maintained in the partition information.The kernel complains with the below message: | sysfs: cannot create duplicate filename '/devices/arm-ffa-8001' | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc7 #8 | Hardware name: FVP Base RevC (DT) | Call trace: | dump_backtrace+0xf8/0x118 | show_stack+0x18/0x24 | dump_stack_lvl+0x50/0x68 | dump_stack+0x18/0x24 | sysfs_create_dir_ns+0xe0/0x13c | kobject_add_internal+0x220/0x3d4 | kobject_add+0x94/0x100 | device_add+0x144/0x5d8 | device_register+0x20/0x30 | ffa_device_register+0x88/0xd8 | ffa_setup_partitions+0x108/0x1b8 | ffa_init+0x2ec/0x3a4 | do_one_initcall+0xcc/0x240 | do_initcall_level+0x8c/0xac | do_initcalls+0x54/0x94 | do_basic_setup+0x1c/0x28 | kernel_init_freeable+0x100/0x16c | kernel_init+0x20/0x1a0 | ret_from_fork+0x10/0x20 | kobject_add_internal failed for arm-ffa-8001 with -EEXIST, don't try to | register things with the same name in the same directory. | arm_ffa arm-ffa: unable to register device arm-ffa-8001 err=-17 | ARM FF-A: ffa_setup_partitions: failed to register partition ID 0x8001By virtue of being random enough to avoid collisions when generated in adistributed system, there is no way to compress UUID keys to the numberof bits required to identify each. We can eliminate '-' in the name butit is not worth eliminating 4 bytes and add unnecessary logic for doingthat. Also v1.0 doesn't provide the UUID of the partitions which makesit hard to use the same for the device name.So to keep it simple, let us alloc an ID using ida_alloc() and append thesame to "arm-ffa" to make up a unique device name. Also stash the id valuein ffa_dev to help freeing the ID later when the device is destroyed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:start_kernel: Add __no_stack_protector function attributeBack during the discussion ofcommit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")we discussed the need for a function attribute to control the omissionof stack protectors on a per-function basis; at the time Clang hadsupport for no_stack_protector but GCC did not. This was fixed ingcc-11. Now that the function attribute is available, let's start usingit.Callers of boot_init_stack_canary need to use this function attributeunless they're compiled with -fno-stack-protector, otherwise the canarystored in the stack slot of the caller will differ upon the call toboot_init_stack_canary. This will lead to a call to __stack_chk_fail()then panic.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Fix handling of lrbp->cmdufshcd_queuecommand() may be called two times in a row for a SCSI commandbefore it is completed. Hence make the following changes: - In the functions that submit a command, do not check the old value of lrbp->cmd nor clear lrbp->cmd in error paths. - In ufshcd_release_scsi_cmd(), do not clear lrbp->cmd.See also scsi_send_eh_cmnd().This commit prevents that the following appears if a command times out:WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8Call trace: ufshcd_queuecommand+0x6f8/0x9a8 scsi_send_eh_cmnd+0x2c0/0x960 scsi_eh_test_devices+0x100/0x314 scsi_eh_ready_devs+0xd90/0x114c scsi_error_handler+0x2b4/0xb70 kthread+0x16c/0x1e0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: drop unnecessary user-triggerable WARN_ONCE in verifierl logIt's trivial for user to trigger "verifier log line truncated" warning,as verifier has a fixed-sized buffer of 1024 bytes (as of now), and there are atleast two pieces of user-provided information that can be output throughthis buffer, and both can be arbitrarily sized by user: - BTF names; - BTF.ext source code lines strings.Verifier log buffer should be properly sized for typical verifier stateoutput. But it's sort-of expected that this buffer won't be long enoughin some circumstances. So let's drop the check. In any case code willwork correctly, at worst truncating a part of a single line output.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: remove BUG_ON()'s in add_new_free_space()At add_new_free_space() we have these BUG_ON()'s that are there to dealwith any failure to add free space to the in memory free space cache.Such failures are mostly -ENOMEM that should be very rare. However there'sno need to have these BUG_ON()'s, we can just return any error to thecaller and all callers and their upper call chain are already dealing witherrors.So just make add_new_free_space() return any errors, while removing theBUG_ON()'s, and returning the total amount of added free space to anoptional u64 pointer argument.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Silence a warning in btf_type_id_size()syzbot reported a warning in [1] with the following stacktrace: WARNING: CPU: 0 PID: 5005 at kernel/bpf/btf.c:1988 btf_type_id_size+0x2d9/0x9d0 kernel/bpf/btf.c:1988 ... RIP: 0010:btf_type_id_size+0x2d9/0x9d0 kernel/bpf/btf.c:1988 ... Call Trace: map_check_btf kernel/bpf/syscall.c:1024 [inline] map_create+0x1157/0x1860 kernel/bpf/syscall.c:1198 __sys_bpf+0x127f/0x5420 kernel/bpf/syscall.c:5040 __do_sys_bpf kernel/bpf/syscall.c:5162 [inline] __se_sys_bpf kernel/bpf/syscall.c:5160 [inline] __x64_sys_bpf+0x79/0xc0 kernel/bpf/syscall.c:5160 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdWith the following btf [1] DECL_TAG 'a' type_id=4 component_idx=-1 [2] PTR '(anon)' type_id=0 [3] TYPE_TAG 'a' type_id=2 [4] VAR 'a' type_id=3, linkage=staticand when the bpf_attr.btf_key_type_id = 1 (DECL_TAG),the following WARN_ON_ONCE in btf_type_id_size() is triggered: if (WARN_ON_ONCE(!btf_type_is_modifier(size_type) && !btf_type_is_var(size_type))) return NULL;Note that 'return NULL' is the correct behavior as we don't wanta DECL_TAG type to be used as a btf_{key,value}_type_id evenfor the case like 'DECL_TAG -> STRUCT'. So thereis no correctness issue here, we just want to silence warning.To silence the warning, I added DECL_TAG as one of kinds inbtf_type_nosize() which will cause btf_type_id_size() returningNULL earlier without the warning. [1] https://lore.kernel.org/bpf/000000000000e0df8d05fc75ba86@google.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Don't retire aborted MMIO instructionReturning an abort to the guest for an unsupported MMIO access is adocumented feature of the KVM UAPI. Nevertheless, it's clear that thisplumbing has seen limited testing, since userspace can trivially cause aWARN in the MMIO return: WARNING: CPU: 0 PID: 30558 at arch/arm64/include/asm/kvm_emulate.h:536 kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 Call trace: kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 kvm_arch_vcpu_ioctl_run+0x98/0x15b4 arch/arm64/kvm/arm.c:1133 kvm_vcpu_ioctl+0x75c/0xa78 virt/kvm/kvm_main.c:4487 __do_sys_ioctl fs/ioctl.c:51 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x1e0/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598The splat is complaining that KVM is advancing PC while an exception ispending, i.e. that KVM is retiring the MMIO instruction despite apending synchronous external abort. Womp womp.Fix the glaring UAPI bug by skipping over all the MMIO emulation incase there is a pending synchronous exception. Note that while userspaceis capable of pending an asynchronous exception (SError, IRQ, or FIQ),it is still safe to retire the MMIO instruction in this case as (1) theyare by definition asynchronous, and (2) KVM relies on hardware supportfor pending/delivering these exceptions instead of the software statemachine for advancing PC.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_fs: Remove WARN_ON in functionfs_bindThis commit addresses an issue related to below kernel panic wherepanic_on_warn is enabled. It is caused by the unnecessary use of WARN_ONin functionsfs_bind, which easily leads to the following scenarios.1.adb_write in adbd 2. UDC write via configfs ================= =====================->usb_ffs_open_thread() ->UDC write ->open_functionfs() ->configfs_write_iter() ->adb_open() ->gadget_dev_desc_UDC_store() ->adb_write() ->usb_gadget_register_driver_owner ->driver_register()->StartMonitor() ->bus_add_driver() ->adb_read() ->gadget_bind_driver() ->configfs_composite_bind() ->usb_add_function()->open_functionfs() ->ffs_func_bind() ->adb_open() ->functionfs_bind() state !=FFS_ACTIVE>The adb_open, adb_read, and adb_write operations are invoked from thedaemon, but trying to bind the function is a process that is invoked byUDC write through configfs, which opens up the possibility of a racecondition between the two paths. In this race scenario, the kernel panicoccurs due to the WARN_ON from functionfs_bind when panic_on_warn isenabled. This commit fixes the kernel panic by removing the unnecessaryWARN_ON.Kernel panic - not syncing: kernel: panic_on_warn set ...[ 14.542395] Call trace:[ 14.542464] ffs_func_bind+0x1c8/0x14a8[ 14.542468] usb_add_function+0xcc/0x1f0[ 14.542473] configfs_composite_bind+0x468/0x588[ 14.542478] gadget_bind_driver+0x108/0x27c[ 14.542483] really_probe+0x190/0x374[ 14.542488] __driver_probe_device+0xa0/0x12c[ 14.542492] driver_probe_device+0x3c/0x220[ 14.542498] __driver_attach+0x11c/0x1fc[ 14.542502] bus_for_each_dev+0x104/0x160[ 14.542506] driver_attach+0x24/0x34[ 14.542510] bus_add_driver+0x154/0x270[ 14.542514] driver_register+0x68/0x104[ 14.542518] usb_gadget_register_driver_owner+0x48/0xf4[ 14.542523] gadget_dev_desc_UDC_store+0xf8/0x144[ 14.542526] configfs_write_iter+0xf0/0x138
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: Uncaught exception in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: Insufficient resource pool in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eth: bnxt: do not update checksum in bnxt_xdp_build_skb()The bnxt_rx_pkt() updates ip_summed value at the end if checksum offloadis enabled.When the XDP-MB program is attached and it returns XDP_PASS, thebnxt_xdp_build_skb() is called to update skb_shared_info.The main purpose of bnxt_xdp_build_skb() is to update skb_shared_info,but it updates ip_summed value too if checksum offload is enabled.This is actually duplicate work.When the bnxt_rx_pkt() updates ip_summed value, it checks if ip_summedis CHECKSUM_NONE or not.It means that ip_summed should be CHECKSUM_NONE at this moment.But ip_summed may already be updated to CHECKSUM_UNNECESSARY in theXDP-MB-PASS path.So the by skb_checksum_none_assert() WARNS about it.This is duplicate work and updating ip_summed in thebnxt_xdp_build_skb() is not needed.Splat looks like:WARNING: CPU: 3 PID: 5782 at ./include/linux/skbuff.h:5155 bnxt_rx_pkt+0x479b/0x7610 [bnxt_en]Modules linked in: bnxt_re bnxt_en rdma_ucm rdma_cm iw_cm ib_cm ib_uverbs veth xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_]CPU: 3 UID: 0 PID: 5782 Comm: socat Tainted: G W 6.14.0-rc4+ #27Tainted: [W]=WARNHardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021RIP: 0010:bnxt_rx_pkt+0x479b/0x7610 [bnxt_en]Code: 54 24 0c 4c 89 f1 4c 89 ff c1 ea 1f ff d3 0f 1f 00 49 89 c6 48 85 c0 0f 84 4c e5 ff ff 48 89 c7 e8 ca 3d a0 c8 e9 8f f4 ff ff <0f> 0b fRSP: 0018:ffff88881ba09928 EFLAGS: 00010202RAX: 0000000000000000 RBX: 00000000c7590303 RCX: 0000000000000000RDX: 1ffff1104e7d1610 RSI: 0000000000000001 RDI: ffff8881c91300b8RBP: ffff88881ba09b28 R08: ffff888273e8b0d0 R09: ffff888273e8b070R10: ffff888273e8b010 R11: ffff888278b0f000 R12: ffff888273e8b080R13: ffff8881c9130e00 R14: ffff8881505d3800 R15: ffff888273e8b000FS: 00007f5a2e7be080(0000) GS:ffff88881ba00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fff2e708ff8 CR3: 000000013e3b0000 CR4: 00000000007506f0PKRU: 55555554Call Trace: ? __warn+0xcd/0x2f0 ? bnxt_rx_pkt+0x479b/0x7610 ? report_bug+0x326/0x3c0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? bnxt_rx_pkt+0x479b/0x7610 ? bnxt_rx_pkt+0x3e41/0x7610 ? __pfx_bnxt_rx_pkt+0x10/0x10 ? napi_complete_done+0x2cf/0x7d0 __bnxt_poll_work+0x4e8/0x1220 ? __pfx___bnxt_poll_work+0x10/0x10 ? __pfx_mark_lock.part.0+0x10/0x10 bnxt_poll_p5+0x36a/0xfa0 ? __pfx_bnxt_poll_p5+0x10/0x10 __napi_poll.constprop.0+0xa0/0x440 net_rx_action+0x899/0xd00...Following ping.py patch adds xdp-mb-pass case. so ping.py is goingto be able to reproduce this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix out-of-bound memcpy() during ethtool -wWhen retrieving the FW coredump using ethtool, it can sometimes causememory corruption:BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45):__bnxt_get_coredump+0x3ef/0x670 [bnxt_en]ethtool_get_dump_data+0xdc/0x1a0__dev_ethtool+0xa1e/0x1af0dev_ethtool+0xa8/0x170dev_ioctl+0x1b5/0x580sock_do_ioctl+0xab/0xf0sock_ioctl+0x1ce/0x2e0__x64_sys_ioctl+0x87/0xc0do_syscall_64+0x5c/0xf0entry_SYSCALL_64_after_hwframe+0x78/0x80...This happens when copying the coredump segment list inbnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.The info->dest_buf buffer is allocated based on the number of coredumpsegments returned by the FW. The segment list is then DMA'ed bythe FW and the length of the DMA is returned by FW. The driver thencopies this DMA'ed segment list to info->dest_buf.In some cases, this DMA length may exceed the info->dest_buf lengthand cause the above BUG condition. Fix it by capping the copylength to not exceed the length of info->dest_buf. The extraDMA data contains no useful information.This code path is shared for the HWRM_DBG_COREDUMP_LIST and theHWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is differentfor these 2 FW commands. To simplify the logic, we need to movethe line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVEup, so that the new check to cap the copy length will work for bothcommands.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: Fix WARN_ON in nouveau_fence_context_kill()Nouveau is mostly designed in a way that it's expected that fences onlyever get signaled through nouveau_fence_signal(). However, in at leastone other place, nouveau_fence_done(), can signal fences, too. If thathappens (race) a signaled fence remains in the pending list for a while,until it gets removed by nouveau_fence_update().Should nouveau_fence_context_kill() run in the meantime, this would bea bug because the function would attempt to set an error code on analready signaled fence.Have nouveau_fence_context_kill() check for a fence being signaled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: Annotate FDB data racesThe 'used' and 'updated' fields in the FDB entry structure can beaccessed concurrently by multiple threads, leading to reports such as[1]. Can be reproduced using [2].Suppress these reports by annotating these accesses usingREAD_ONCE() / WRITE_ONCE().[1]BUG: KCSAN: data-race in vxlan_xmit / vxlan_xmitwrite to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0: vxlan_xmit+0xb29/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7fread to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2: vxlan_xmit+0xadf/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7fvalue changed: 0x00000000fffbac6e -> 0x00000000fffbac6fReported by Kernel Concurrency Sanitizer on:CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014[2] #!/bin/bash set +H echo whitelist > /sys/kernel/debug/kcsan echo !vxlan_xmit > /sys/kernel/debug/kcsan ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1 bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1 taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q & taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabledWhen attempting to enable MQPRIO while HTB offload is alreadyconfigured, the driver currently returns `-EINVAL` and triggers a`WARN_ON`, leading to an unnecessary call trace.Update the code to handle this case more gracefully by returning`-EOPNOTSUPP` instead, while also providing a helpful user message.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_ffa: Set dma_mask for ffa devicesSet dma_mask for FFA devices, otherwise DMA allocation using the device pointerlead to following warning:WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: cx231xx: set device_caps for 417The video_device for the MPEG encoder did not set device_caps.Add this, otherwise the video device can't be registered (you get aWARN_ON instead).Not seen before since currently 417 support is disabled, but I foundthis while experimenting with it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu().As syzbot reported [0], mpls_route_input_rcu() can be calledfrom mpls_getroute(), where is under RTNL.net->mpls.platform_label is only updated under RTNL.Let's use rcu_dereference_rtnl() in mpls_route_input_rcu() tosilence the splat.[0]:WARNING: suspicious RCU usage6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted ----------------------------net/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 11 lock held by syz.2.4451/17730: #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline] #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961stack backtrace:CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865 mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84 mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381 rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964 netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmmsg+0x200/0x420 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f0a2818e969Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix the setting of capabilities when automounting a new filesystemCapabilities cannot be inherited when we cross into a new filesystem.They need to be reset to the minimal defaults, and then probed foragain.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: Remove WARN_ON for device endpoint command timeoutsThis commit addresses a rarely observed endpoint command timeoutwhich causes kernel panic due to warn when 'panic_on_warn' is enabledand unnecessary call trace prints when 'panic_on_warn' is disabled.It is seen during fast software-controlled connect/disconnect testcases.The following is one such endpoint command timeout that we observed:1. Connect =======->dwc3_thread_interrupt ->dwc3_ep0_interrupt ->configfs_composite_setup ->composite_setup ->usb_ep_queue ->dwc3_gadget_ep0_queue ->__dwc3_gadget_ep0_queue ->__dwc3_ep0_do_control_data ->dwc3_send_gadget_ep_cmd2. Disconnect ==========->dwc3_thread_interrupt ->dwc3_gadget_disconnect_interrupt ->dwc3_ep0_reset_state ->dwc3_ep0_end_control_data ->dwc3_send_gadget_ep_cmdIn the issue scenario, in Exynos platforms, we observed that controltransfers for the previous connect have not yet been completed and endtransfer command sent as a part of the disconnect sequence andprocessing of USB_ENDPOINT_HALT feature request from the host timeout.This maybe an expected scenario since the controller is processing EPcommands sent as a part of the previous connect. It maybe better toremove WARN_ON in all places where device endpoint commands are sent toavoid unnecessary kernel panic due to warn.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Prevent access to vCPU events before initAnother day, another syzkaller bug. KVM erroneously allows userspace topend vCPU events for a vCPU that hasn't been initialized yet, leading toKVM interpreting a bunch of uninitialized garbage for routing /injecting the exception.In one case the injection code and the hyp disagree on whether the vCPUhas a 32bit EL1 and put the vCPU into an illegal mode for AArch64,tripping the BUG() in exception_target_el() during the next injection: kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)Reject the ioctls outright as no sane VMM would call these beforeKVM_ARM_VCPU_INIT anyway. Even if it did the exception would've beenthrown away by the eventual reset of the vCPU's state.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ixgbevf: fix mailbox API compatibility by negotiating supported featuresThere was backward compatibility in the terms of mailbox API. Variousdrivers from various OSes supporting 10G adapters from Intel portfoliocould easily negotiate mailbox API.This convention has been broken since introducing API 1.4.Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added supportfor IPSec which is specific only for the kernel ixgbe driver. None of therest of the Intel 10G PF/VF drivers supports it. And actually lack ofsupport was not included in the IPSec implementation - there were no suchcode paths. No possibility to negotiate support for the feature wasintroduced along with introduction of the feature itself.Commit 339f28964147 ("ixgbevf: Add support for new mailbox communicationbetween PF and VF") increasing API version to 1.5 did the same - itintroduced code supported specifically by the PF ESX driver. It altered APIversion for the VF driver in the same time not touching the versiondefined for the PF ixgbe driver. It led to additional discrepancies,as the code provided within API 1.6 cannot be supported for Linux ixgbedriver as it causes crashes.The issue was noticed some time ago and mitigated by Jake within the commitd0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5").As a result we have regression for IPsec support and after increasing APIto version 1.6 ixgbevf driver stopped to support ESX MBX.To fix this mess add new mailbox op asking PF driver about supportedfeatures. Basing on a response determine whether to set support for IPSecand ESX-specific enhanced mailbox.New mailbox op, for compatibility purposes, must be added within new APIrevision, as API version of OOT PF & VF drivers is already increased to1.6 and doesn't incorporate features negotiate op.Features negotiation mechanism gives possibility to be extended with newfeatures when needed in the future.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.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 == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).
-
Description: Perl versions from 5.9.4 before 5.40.4-RC1, from 5.41.0 before 5.42.2-RC1, from 5.43.0 before 5.43.9 contain a vulnerable version of Compress::Raw::Zlib.Compress::Raw::Zlib is included in the Perl package as a dual-life core module, and is vulnerable to CVE-2026-3381 due to a vendored version of zlib which has several vulnerabilities, including CVE-2026-27171. The bundled Compress::Raw::Zlib was updated to version 2.221 in Perl blead commit c75ae9cc164205e1b6d6dbd57bd2c65c8593fe94.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libz1 > 0-0 (version in image is 1.2.13-150500.4.6.1).
-
Description: Vim is an open source, command line text editor. Prior to version 9.2.0383, an OS command injection vulnerability exists in the netrw standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the sftp:// or file:// protocol handlers), an attacker can execute arbitrary shell commands with the privileges of the Vim process. This issue has been patched in version 9.2.0383.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- vim > 0-0 (version in image is 9.2.0280-150500.20.46.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio_ring: Fix data race by tagging event_triggered as racy for KCSANsyzbot reports a data-race when accessing the event_triggered, here is thesimplified stack when the issue occurred:==================================================================BUG: KCSAN: data-race in virtqueue_disable_cb / virtqueue_enable_cb_delayedwrite to 0xffff8881025bc452 of 1 bytes by task 3288 on cpu 0: virtqueue_enable_cb_delayed+0x42/0x3c0 drivers/virtio/virtio_ring.c:2653 start_xmit+0x230/0x1310 drivers/net/virtio_net.c:3264 __netdev_start_xmit include/linux/netdevice.h:5151 [inline] netdev_start_xmit include/linux/netdevice.h:5160 [inline] xmit_one net/core/dev.c:3800 [inline]read to 0xffff8881025bc452 of 1 bytes by interrupt on cpu 1: virtqueue_disable_cb_split drivers/virtio/virtio_ring.c:880 [inline] virtqueue_disable_cb+0x92/0x180 drivers/virtio/virtio_ring.c:2566 skb_xmit_done+0x5f/0x140 drivers/net/virtio_net.c:777 vring_interrupt+0x161/0x190 drivers/virtio/virtio_ring.c:2715 __handle_irq_event_percpu+0x95/0x490 kernel/irq/handle.c:158 handle_irq_event_percpu kernel/irq/handle.c:193 [inline]value changed: 0x01 -> 0x00==================================================================When the data race occurs, the function virtqueue_enable_cb_delayed() setsevent_triggered to false, and virtqueue_disable_cb_split/packed() reads itas false due to the race condition. Since event_triggered is an unreliablehint used for optimization, this should only cause the driver temporarilysuggest that the device not send an interrupt notification when the eventindex is used.Fix this KCSAN reported data-race issue by explicitly tagging the access asdata_racy.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.149.1).