Re: [PATCH v4] net: 9p: avoid freeing uninit memory in p9pdu_vreadf

[Christian Schoenebeck <linux_oss@crudebyte.com>]

On Wednesday, December 6, 2023 9:09:13 PM CET Fedor Pchelkin wrote:
> If some of p9pdu_readf() calls inside case 'T' in p9pdu_vreadf() fails,
> the error path is not handled properly. *wnames or members of *wnames
> array may be left uninitialized and invalidly freed.
> 
> Initialize *wnames to NULL in beginning of case 'T'. Initialize the first
> *wnames array element to NULL and nullify the failing *wnames element so
> that the error path freeing loop stops on the first NULL element and
> doesn't proceed further.
> 
> Found by Linux Verification Center (linuxtesting.org).
> 
> Fixes: ace51c4dd2f9 ("9p: add new protocol support code")
> Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
> ---
> v2: I've missed that *wnames can also be left uninitialized. Please
> ignore the patch v1. As an answer to Dominique's comment: my
> organization marks this statement in all commits.
> v3: Simplify the patch by using kcalloc() instead of array indices
> manipulation per Christian Schoenebeck's remark. Update the commit
> message accordingly.
> v4: Per Christian's suggestion, apply another strategy: mark failing
> array element as NULL and move in the freeing loop until it is found.
> Update the commit message accordingly. If v4 is more appropriate than the
> version at
> https://github.com/martinetd/linux/commit/69cc23eb3a0b79538e9b5face200c4cd5cd32ae0
> then please use it, otherwise, I don't think we can provide more
> convenient solution here than the one already queued at github.
> 
>  net/9p/protocol.c | 17 +++++++++++++----
>  1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/net/9p/protocol.c b/net/9p/protocol.c
> index 4e3a2a1ffcb3..0e6603b1ec90 100644
> --- a/net/9p/protocol.c
> +++ b/net/9p/protocol.c
> @@ -394,6 +394,8 @@ p9pdu_vreadf(struct p9_fcall *pdu, int proto_version, const char *fmt,
>  				uint16_t *nwname = va_arg(ap, uint16_t *);
>  				char ***wnames = va_arg(ap, char ***);
>  
> +				*wnames = NULL;
> +
>  				errcode = p9pdu_readf(pdu, proto_version,
>  								"w", nwname);
>  				if (!errcode) {
> @@ -403,6 +405,8 @@ p9pdu_vreadf(struct p9_fcall *pdu, int proto_version, const char *fmt,
>  							  GFP_NOFS);
>  					if (!*wnames)
>  						errcode = -ENOMEM;
> +					else
> +						(*wnames)[0] = NULL;
>  				}
>  
>  				if (!errcode) {
> @@ -414,8 +418,10 @@ p9pdu_vreadf(struct p9_fcall *pdu, int proto_version, const char *fmt,
>  								proto_version,
>  								"s",
>  								&(*wnames)[i]);
> -						if (errcode)
> +						if (errcode) {
> +							(*wnames)[i] = NULL;
>  							break;
> +						}

I just checked whether this could create a leak, but it looks clean, so LGTM:

Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>

Dominique, I would tend to use this v4 instead of v2. What do you think?

>  					}
>  				}
>  
> @@ -423,11 +429,14 @@ p9pdu_vreadf(struct p9_fcall *pdu, int proto_version, const char *fmt,
>  					if (*wnames) {
>  						int i;
>  
> -						for (i = 0; i < *nwname; i++)
> +						for (i = 0; i < *nwname; i++) {
> +							if (!(*wnames)[i])
> +								break;
>  							kfree((*wnames)[i]);
> +						}
> +						kfree(*wnames);
> +						*wnames = NULL;
>  					}
> -					kfree(*wnames);
> -					*wnames = NULL;
>  				}
>  			}
>  			break;
>