From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-186.mta1.migadu.com (out-186.mta1.migadu.com [95.215.58.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7AC23283C89 for ; Thu, 9 Apr 2026 03:11:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.186 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775704310; cv=none; b=cp41387lJeLTd1V2L6WUn2dZ1VYCUFj4F4shAv2FXX8oYIH3Sdra3vR0nGrF/nzP8cJF/bZXkym9H1BAfrUjMCj8mI1mny1F+K9Ub+Ihz/+HG3HU93mPobxlpDGeXKhgMK5pqJMksSvG9PkocaKLaUmDFAqDsjzKtKFEa+TKqgE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775704310; c=relaxed/simple; bh=BKu6slQSA59rMwyjMqQttlERuky3a+Q080V04uN6zGo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=YEdP9rT9oJYCwRfSmFN7U05E3zOpFiWNUUvyqg8p1S4XGKuO/cCUMIqgErewJmmNUh4furOjD0XqOpL+65ycyzCZ5itUPUafSVHLYZgGN9fINWz+A6YcLNfmCxJf3l710CjVhlSGtkmAdwBAUq5yJ1AehWSwMXnT2IVCyxjb3Y8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=chenxiaosong.com; spf=pass smtp.mailfrom=chenxiaosong.com; dkim=pass (2048-bit key) header.d=chenxiaosong.com header.i=@chenxiaosong.com header.b=g9AgRE7c; arc=none smtp.client-ip=95.215.58.186 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=chenxiaosong.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chenxiaosong.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=chenxiaosong.com header.i=@chenxiaosong.com header.b="g9AgRE7c" Message-ID: <77013349-ff89-4593-985d-520d967d2638@chenxiaosong.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chenxiaosong.com; s=key1; t=1775704306; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iy2d63mOs0uVe10NEgVk9hD0DgC4FR98sN+wcxJYrDM=; b=g9AgRE7cvI3s6sDV56zddFWQ6Q3vG0XjFOcQPWu4HWoUH9jVNpdnqgLnq9PNgN1+nGzAi4 y27Y6uNlIQoAPklwrBsnbWaYqZvhqllwRxI0MwKa1eCEo1j7/OfHMje4yORFigCk7utgzI 8ep0QJndFPa9UoGk9jMSpidyWwgvLyzgyikOwJOnYXgoxVnnHfQ1GiQIOI9dVaq6EFcae5 6INw2r+iTS+phJwpp1A8QJzQot+jWQgbwy51fMVHhmmwfAFqRat6LHzC+cKohwE8m27H0X raRDWroYnVSD8bC9cDv6zCcKaKVYtgEsixK5A7D8Qf7UVC8bTm3P7nIGY/SDcg== Date: Thu, 9 Apr 2026 11:09:47 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 1/2] smb: client: fix off-by-8 bounds check in check_wsl_eas() To: Steve French Cc: linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org, Paulo Alcantara , Greg Kroah-Hartman , Ronnie Sahlberg , Shyam Prasad N , Tom Talpey , Bharath SM , samba-technical@lists.samba.org, stable References: <2026040635-banking-unsoiled-3250@gregkh> <2026040636-unsigned-jackal-e239@gregkh> <2026040822-shortly-chump-8518@gregkh> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: ChenXiaoSong In-Reply-To: <2026040822-shortly-chump-8518@gregkh> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT Hi Steve, Should we use `get_unaligned_le32()` to get unaligned data? > static inline kuid_t wsl_make_kuid(struct cifs_sb_info *cifs_sb, > void *ptr) > { > u32 uid = le32_to_cpu(*(__le32 *)ptr); > ... > } > > Additionally, does parsing these extended attributes cause unaligned memory > accesses? > When parsing WSL extended attributes, the code derives the value pointer > at an offset of ea_name_length (which is 6) plus 1 from ea_data. Since > ea is a 4-byte aligned structure, the value sits at an unaligned offset. > Helper functions like wsl_make_kuid() explicitly cast this unaligned > pointer to a 32-bit type and dereference it: > le32_to_cpu(*(__le32 *)v); > > Could this trigger an unaligned access exception and crash the kernel on > architectures with strict alignment requirements? -- ChenXiaoSong Chinese Homepage: chenxiaosong.com English Homepage: chenxiaosong.com/en