Author: sobomax
Date: Tue Dec  4 21:48:56 2018
New Revision: 341494
URL: https://svnweb.freebsd.org/changeset/base/341494

Log:
  Another attempt to fix issue with the DIOCGDELETE ioctl(2) not
  handling slightly out-of-bound requests properly (r340187).
  Perform range check here rather then rely on g_delete_data() to DTRT.
  
  The g_delete_data() would always return success for requests
  starting just the next byte after providers media boundary.
  
  MFC after:    4 weeks

Modified:
  head/sys/geom/geom_dev.c

Modified: head/sys/geom/geom_dev.c
==============================================================================
--- head/sys/geom/geom_dev.c    Tue Dec  4 20:40:28 2018        (r341493)
+++ head/sys/geom/geom_dev.c    Tue Dec  4 21:48:56 2018        (r341494)
@@ -583,6 +583,20 @@ g_dev_ioctl(struct cdev *dev, u_long cmd, caddr_t data
                        error = EINVAL;
                        break;
                }
+               if ((cp->provider->mediasize > 0) &&
+                   (offset >= cp->provider->mediasize)) {
+                       /*
+                        * Catch out-of-bounds requests here. The problem is
+                        * that due to historical GEOM I/O implementation
+                        * peculatities, g_delete_data() would always return
+                        * success for requests starting just the next byte
+                        * after providers media boundary. Condition check on
+                        * non-zero media size, since that condition would
+                        * (most likely) cause ENXIO instead.
+                        */
+                       error = EIO;
+                       break;
+               }
                while (length > 0) {
                        chunk = length;
                        if (g_dev_del_max_sectors != 0 && chunk >
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Reply via email to