Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 May 2019 07:42:31 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 238014] Potential NULL pointer dereference in function ata_dev_advinfo and nvme_dev_advinfo
Message-ID:  <bug-238014-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238014

            Bug ID: 238014
           Summary: Potential NULL pointer dereference in function
                    ata_dev_advinfo and nvme_dev_advinfo
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: yangx92@hotmail.com

Created attachment 204502
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D204502&action=
=3Dedit
Proposed patch

There are two NULL pointer vulnerabilities in functions named ata_dev_advin=
fo
(sys/cam/ata/ata_xpt.c) and nvme_dev_advinfo (sys/cam/nvme/nvme_xpt.c).

We take function ata_dev_advinfo for example.

                if (cdai->flags & CDAI_FLAG_STORE) {
                        if (device->physpath !=3D NULL)
                                free(device->physpath, M_CAMXPT);
                        device->physpath_len =3D cdai->bufsiz;
                        /* Clear existing buffer if zero length */
                        if (cdai->bufsiz =3D=3D 0)
                                break;
                        device->physpath =3D malloc(cdai->bufsiz, M_CAMXPT,
M_NOWAIT);
                        if (device->physpath =3D=3D NULL) {
                                start_ccb->ccb_h.status =3D CAM_REQ_ABORTED;
                                return;
                        }
                        memcpy(device->physpath, cdai->buf, cdai->bufsiz);


if the physical path is being stored and there is a malloc failure (malloc(=
9)
is called with M_NOWAIT), we could wind up in a situation where the device's
physpath_len is set to the length the user provided, but the physpath itsel=
f is
NULL.

If another context then comes in to fetch the physical path value, we would
wind up trying to memcpy a NULL pointer into the caller's buffer.

So, set the physpath_len to 0 when we free the physpath on entry into the s=
tore
case for the physical path.  Reset the length to a non-zero value only after
we've successfully malloced a buffer to hold it.

The attachment is the proposed patch.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-238014-227>