From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f73.google.com (mail-ed1-f73.google.com [209.85.208.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 158B8405C4A for ; Thu, 4 Jun 2026 11:11:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780571502; cv=none; b=MRBvXSmzrrmoec/agc65VxWEo8VYKOsSdejrcZf6taF1+3oZiOKUDccmIFBG2M4EXOos5jXad125GuJwRkrUhrqf/olvokldLpWiIIXCeUJv8aGFK7xrkReqM3InqS5wxcEwuL8V3+ZBl66X6jIit1TVPQJa4yFErq3zpizNhfw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780571502; c=relaxed/simple; bh=24bfCzm+uDUdGN8ThiJCRYe4QRj5R4c1E/88xKf9quQ=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=TzXqPne/+sWqYCvTwna/hIevWa/66yGhACe8OqHiCihy53+JOtTnrIwL7NJqrQ/2E1NN9cOgK/VkfHpTFCpneRAOqEjK9iO4EwkNNVvg7SLiVHx+a2IiuMU+X8RELqid3N3qmgfScdSN1RRG7EEM6gfFwA23hjOiDTXoFKBh1sc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Kr754v1B; arc=none smtp.client-ip=209.85.208.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Kr754v1B" Received: by mail-ed1-f73.google.com with SMTP id 4fb4d7f45d1cf-68d9309b510so591620a12.3 for ; Thu, 04 Jun 2026 04:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1780571499; x=1781176299; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=jMRMPrJmpp7pwM3jJPsZRMxWCH+VDxgazfQtjGEX9h0=; b=Kr754v1B4kj5gOpMko03TwIKLBNs++tx2GmtwZOGguWpipDQLZKrAOGRUppk43sqH2 6GhN8e0BYgD6MNcnrGpBdkGpepDXK6py+AIk/xn86fmqMDArF3Y6aHJcqmI0OJkypoVs JVD6tnMKbuXAb8vIg5jXB0Y4Zxf4MyNzLYv5FPuGyjgT7zc9dbmIxaVxcBHR+98pc5bQ p8557HwLQQp4gdLTruqWAkCJ4JixeQo1oAToMrHp/MAX+MAn9VCE8nYTVuVaTgwdSFUh HpTsSrEyniox5u7r+yUavtozdLb/vtCGVpPtiPX7kKpqDJOmzID3JeW0MuS0qf0aV9jD CpEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780571499; x=1781176299; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jMRMPrJmpp7pwM3jJPsZRMxWCH+VDxgazfQtjGEX9h0=; b=J0lRG2p64LovM/13wcqk0K1Mgas1JEufSTR8QQnFqyATTKkQ/dDHg5mLRp6tg2BGbX BJMZrBsrR6b55Ple721hK63/3GvB4FbliAqeceRirOfFSs+WUKzsgGnyKQs0PIJZcob+ ad7E/jlb09DyGYevP6wjeiVjsReF3+FhyBVlrSRl3LrCDgTuf1B1YEqAWxizqG5fT497 1KnDDEA5DDNuS+1UoyUrpyBoaAEWG3Ta4m6ejFE6+5hKua9xoNijNRTyeINKGrwfZiY9 k2VLFSKeuKOTQTB1x9EFA2M12Qsjj4Z98mOIPojXR4EgZlW6HTZTpyArlsHANAI3fABv sOAA== X-Forwarded-Encrypted: i=1; AFNElJ9dTCz08p25qPA9+oFcjfyaMPAW9y/pPx3T69tk3JbIR/LmSPV65yUIzIiF2soke/vpeVmIOb4uTgI4k8A=@vger.kernel.org X-Gm-Message-State: AOJu0Yx19rFldQlhXu7JO/0vhT/Yqrjpre5vePVOVra11OYIKNGCiltO g1u270ZexDq1YruhWq9hN4vfR9Itra0lqFERb4Zn8SwRzttH08TjNpTUPj7BSZo29SAHEjsyTKl 8NcJSqPQM3eJzZkQgkg== X-Received: from edre22.prod.google.com ([2002:a50:ec96:0:b0:68b:edb5:9940]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6402:2808:b0:688:1efa:2605 with SMTP id 4fb4d7f45d1cf-68e70039324mr3884692a12.6.1780571499211; Thu, 04 Jun 2026 04:11:39 -0700 (PDT) Date: Thu, 4 Jun 2026 11:11:37 +0000 In-Reply-To: <20260603174506.1957278-1-clm@meta.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260603174506.1957278-1-clm@meta.com> Message-ID: Subject: Re: [PATCH] binder: cache secctx size before release zeroes it From: Alice Ryhl To: Chris Mason Cc: gregkh@linuxfoundation.org, christian@brauner.io, cmllamas@google.com, arve@android.com, tkjos@android.com, casey@schaufler-ca.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" On Wed, Jun 03, 2026 at 10:44:54AM -0700, Chris Mason wrote: > binder_transaction() bounds the scatter-gather buffer area with > sg_buf_end_offset and subtracts the aligned LSM context size because > the secctx is written at the tail of that area. The subtraction reads > lsmctx.len, but that field has already been cleared by the time the > line runs: > > security_secid_to_secctx(secid, &lsmctx) /* lsmctx.len set */ > lsmctx_aligned_size = ALIGN(lsmctx.len, sizeof(u64)) > extra_buffers_size += lsmctx_aligned_size > ... > security_release_secctx(&lsmctx) /* memset zeroes len */ > ... > sg_buf_end_offset = sg_buf_offset + extra_buffers_size > - ALIGN(lsmctx.len, sizeof(u64)) /* ALIGN(0,8) */ > > security_release_secctx() does memset(cp, 0, sizeof(*cp)), so lsmctx.len > reads back as 0 and the subtraction contributes nothing, leaving > sg_buf_end_offset too large by the aligned secctx size on every > transaction to a txn_security_ctx node. > > Each BINDER_TYPE_PTR object then derives buf_left = sg_buf_end_offset - > sg_buf_offset as the sole upper bound on its copy, so the inflated end > offset lets the copy run into the bytes that already hold the secctx. > > The aligned size must therefore be cached before release rather than > re-read from the now-cleared field. Fix by caching it in > lsmctx_aligned_size at function scope when it is first computed and > subtracting lsmctx_aligned_size instead of re-reading lsmctx.len after > release. Reuse the same value for the earlier buf_offset computation. > > Fixes: 6fba89813ccf ("lsm: ensure the correct LSM context releaser") > Cc: stable@vger.kernel.org > Assisted-by: kres:claude-opus-4-8 > Signed-off-by: Chris Mason Reviewed-by: Alice Ryhl