mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alex Elder <elder@ieee.org>
To: Suraj Sonawane <surajsonawane0215@gmail.com>,
	johan@kernel.org, elder@kernel.org, gregkh@linuxfoundation.org
Cc: greybus-dev@lists.linaro.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] greybus: Fix null pointer dereference in gb_operation_response_send()
Date: Sun, 27 Oct 2024 09:00:42 -0500	[thread overview]
Message-ID: <106ff2db-befc-4899-8f28-6f8b6276cdd3@ieee.org> (raw)
In-Reply-To: <20241027075304.7301-1-surajsonawane0215@gmail.com>

On 10/27/24 2:53 AM, Suraj Sonawane wrote:
> Fix an issue detected by the Smatch static tool:
> drivers/greybus/operation.c:852 gb_operation_response_send() error:
> we previously assumed 'operation->response' could be null (see line 829)

There is no need for this.  This is a case where the code is
doing something that is too involved for "smatch" to know
things are OK.

A unidirectional operation includes only a request message, but
no response message.

There are two cases:
- Unidirectional
   - There is no response buffer
   - There will be no call to gb_operation_response_alloc(),
     because the operation is unidirectional.
   - The result gets set with the errno value.  If there's
     an error (there shouldn't be), -EIO is returned.
   - We return 0 early, because it's a unidirectional operation.
- Not unidirectional
   - If there is a response, we attempt to allocate one.  If that
     fails, we return -ENOMEM early.
   - Otherwise there *is* a response (it was successfully allocated)
   - The result is set
   - It is not unidirectional, so we get a reference to the operation,
     add it to the active list (or skip to the end if not connected)
   - We record the result in the response header.  This is the line in
     question, but we know the response pointer is good.
   - We send the response.
   - On error, we drop or references and return the error code.

					-Alex



> The issue occurs because 'operation->response' may be null if the
> response allocation fails at line 829. However, the code tries to
> access 'operation->response->header' at line 852 without checking if
> it was successfully allocated. This can cause a crash if 'response'
> is null.
> 
> To fix this, add a check to ensure 'operation->response' is not null
> before accessing its header. If the response is null, log an error
> message and return -ENOMEM to stop further processing, preventing
> any crashes or undefined behavior.
> 
> Signed-off-by: Suraj Sonawane <surajsonawane0215@gmail.com>
> ---
>   drivers/greybus/operation.c | 8 +++++++-
>   1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/greybus/operation.c b/drivers/greybus/operation.c
> index 8459e9bc0..521899fbc 100644
> --- a/drivers/greybus/operation.c
> +++ b/drivers/greybus/operation.c
> @@ -849,7 +849,13 @@ static int gb_operation_response_send(struct gb_operation *operation,
>   		goto err_put;
>   
>   	/* Fill in the response header and send it */
> -	operation->response->header->result = gb_operation_errno_map(errno);
> +	if (operation->response) {
> +		operation->response->header->result = gb_operation_errno_map(errno);
> +	} else {
> +		dev_err(&connection->hd->dev, "failed to allocate response\n");
> +		ret = -ENOMEM;
> +		goto err_put_active;
> +	}
>   
>   	ret = gb_message_send(operation->response, GFP_KERNEL);
>   	if (ret)


  parent reply	other threads:[~2024-10-27 14:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-27  7:53 Suraj Sonawane
2024-10-27 13:57 ` Peter Seiderer
2024-10-28 12:39   ` Suraj Sonawane
2024-10-27 14:00 ` Alex Elder [this message]
2024-10-28 12:43   ` Suraj Sonawane

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=106ff2db-befc-4899-8f28-6f8b6276cdd3@ieee.org \
    --to=elder@ieee.org \
    --cc=elder@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=greybus-dev@lists.linaro.org \
    --cc=johan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=surajsonawane0215@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®