[Bug 238014] Potential NULL pointer dereference in function ata_dev_advinfo and nvme_dev_advinfo

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Tue May 21 07:42:34 UTC 2019


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238014

            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 at FreeBSD.org
          Reporter: yangx92 at hotmail.com

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

There are two NULL pointer vulnerabilities in functions named ata_dev_advinfo
(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 != NULL)
                                free(device->physpath, M_CAMXPT);
                        device->physpath_len = cdai->bufsiz;
                        /* Clear existing buffer if zero length */
                        if (cdai->bufsiz == 0)
                                break;
                        device->physpath = malloc(cdai->bufsiz, M_CAMXPT,
M_NOWAIT);
                        if (device->physpath == NULL) {
                                start_ccb->ccb_h.status = 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 itself 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 store
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.

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


More information about the freebsd-bugs mailing list