public inbox for ntfs3@lists.linux.dev
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: almaz.alexandrovich@paragon-software.com
Cc: ntfs3@lists.linux.dev
Subject: [bug report] fs/ntfs3: inconsistent NULL checking in attr_set_size()
Date: Tue, 24 Aug 2021 14:40:20 +0300	[thread overview]
Message-ID: <20210824114020.GD31143@kili> (raw)

Hello Konstantin Komarov,

This is a semi-automatic email about new static checker warnings.

The patch be71b5cba2e6: "fs/ntfs3: Add attrib operations" from Aug
13, 2021, leads to the following Smatch complaint:

    fs/ntfs3/attrib.c:764 attr_set_size()
    error: we previously assumed 'le' could be null (see line 703)

fs/ntfs3/attrib.c
   702					goto out;
   703			} else if (le && le->vcn) {
                                   ^^
This code assumes "le" can be NULL.

   704				u16 le_sz = le16_to_cpu(le->size);
   705	
   706				/*
   707				 * NOTE: list entries for one attribute are always
   708				 * the same size. We deal with last entry (vcn==0)
   709				 * and it is not first in entries array
   710				 * (list entry for std attribute always first)
   711				 * So it is safe to step back
   712				 */
   713				mi_remove_attr(mi, attr);
   714	
   715				if (!al_remove_le(ni, le)) {
   716					err = -EINVAL;
   717					goto out;
   718				}
   719	
   720				le = (struct ATTR_LIST_ENTRY *)((u8 *)le - le_sz);
   721			} else {
   722				attr->nres.evcn = cpu_to_le64((u64)vcn - 1);
   723				mi->dirty = true;
   724			}
   725	
   726			attr_b->nres.alloc_size = cpu_to_le64(new_alloc_tmp);
   727	
   728			if (vcn == new_alen) {
   729				attr_b->nres.data_size = cpu_to_le64(new_size);
   730				if (new_size < old_valid)
   731					attr_b->nres.valid_size =
   732						attr_b->nres.data_size;
   733			} else {
   734				if (new_alloc_tmp <=
   735				    le64_to_cpu(attr_b->nres.data_size))
   736					attr_b->nres.data_size =
   737						attr_b->nres.alloc_size;
   738				if (new_alloc_tmp <
   739				    le64_to_cpu(attr_b->nres.valid_size))
   740					attr_b->nres.valid_size =
   741						attr_b->nres.alloc_size;
   742			}
   743	
   744			if (is_ext)
   745				le64_sub_cpu(&attr_b->nres.total_size,
   746					     ((u64)alen << cluster_bits));
   747	
   748			mi_b->dirty = true;
   749	
   750			if (new_alloc_tmp <= new_alloc)
   751				goto ok;
   752	
   753			old_size = new_alloc_tmp;
   754			vcn = svcn - 1;
   755	
   756			if (le == le_b) {
   757				attr = attr_b;
   758				mi = mi_b;
   759				evcn = svcn - 1;
   760				svcn = 0;
   761				goto next_le;
   762			}
   763	
   764			if (le->type != type || le->name_len != name_len ||
                            ^^^^^^^^
Unchecked dereference.

   765			    memcmp(le_name(le), name, name_len * sizeof(short))) {
   766				err = -EINVAL;

regards,
dan carpenter

                 reply	other threads:[~2021-08-24 11:40 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20210824114020.GD31143@kili \
    --to=dan.carpenter@oracle.com \
    --cc=almaz.alexandrovich@paragon-software.com \
    --cc=ntfs3@lists.linux.dev \
    /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