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