Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Kees Cook <keescook@chromium.org>
To:     haifeng.xu@shopee.com, brauner@kernel.org
Cc:     Kees Cook <keescook@chromium.org>, elver@google.com,
        oleg@redhat.com, ebiederm@xmission.com,
        linux-kernel@vger.kernel.org, tglx@linutronix.de,
        peterz@infradead.org
Subject: Re: [PATCH] signal: Initialize the info in ksignal
Date:   Thu,  1 Dec 2022 15:42:28 -0800
Message-Id: <166993814728.941514.14527504091820169396.b4-ty@chromium.org>
In-Reply-To: <20221128065606.19570-1-haifeng.xu@shopee.com>
References: <20221128065606.19570-1-haifeng.xu@shopee.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Mon, 28 Nov 2022 06:56:06 +0000, haifeng.xu wrote:
> When handing the SIGNAL_GROUP_EXIT flag, the info in ksignal isn't cleared.
> However, the info acquired by dequeue_synchronous_signal/dequeue_signal is
> initialized and can be safely used. Fortunately, the fatal signal process
> just uses the si_signo and doesn't use any other member. Even so, the
> initialization before use is more safer.
> 
> 
> [...]

Applied to for-next/hardening, thanks!

[1/1] signal: Initialize the info in ksignal
      https://git.kernel.org/kees/c/935d428bb528

-- 
Kees Cook