lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101212232705.4d14e89c@lembas.zaitcev.lan>
Date:	Sun, 12 Dec 2010 23:27:05 -0700
From:	Pete Zaitcev <zaitcev@...hat.com>
To:	morroww6@...scape.net
Cc:	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
	zaitcev@...hat.com, nm127@...email.hu
Subject: Re: [PATCH 1/1] usbmon:  usb monitor binary data incorrectly
 reported for isoc transfers

On Sun, 12 Dec 2010 17:15:21 -0500 (EST)
morroww6@...scape.net wrote:

> Since your patch can cause alot of extra data to be sent, I suggest looking
> into this patch before your usbmon become publicized.

Usbmon was publicised for years now, but let's see.

> Corrects isoc monitor data payload to represent the "actual_length"s
> of urb buffer data instead of "length" of buffer data.
> Since isoc records are a series of fragments, uninitialized buffer
> data could be sent as monitor data.

As an aside, there is no security or privacy issue with fetching
the "unitialized" data (it is the same ring buffer, so unrelated
kernel memory does not leak).

> -       if (urb->num_sgs == 0) {
> -               mon_copy_to_buff(rp, offset, urb->transfer_buffer, length);
> -               length = 0;
> -       } else {
> +       if (!ndesc && urb->num_sgs > 0) {
> +               struct scatterlist *sg;
>                 /* If IOMMU coalescing occurred, we cannot trust sg_page */
>[............]
>                         *flag = 'D';
> +       } else {
> +               if (ndesc) {
> +                       struct usb_iso_packet_descriptor *fp;
>[............]
> +               }
> +               else {
> +                       mon_copy_to_buff(rp, offset, buf, length);
> +                       length = 0;
> +               }
>         }

This looks obviously incorrect. If anyone ever submits an ISO with
the newfanged s/g URB, we're going to copy the scatterlist (if not
crash).

> +                       fp = urb->iso_frame_desc;
> +                       for (i=ndesc; length > 0 && --i >= 0; ++fp) {
> +                               this_ofs = fp->offset;
> +                               this_len = min_t(unsigned int, fp->actual_length, length);
> +                               offset = mon_copy_to_buff(rp, offset, buf+this_ofs, this_len);
> +                               length -= this_len;
> +                       }

This is no better. It is not going to save anything from outgoing
transfers, where actual_lengh is not set.

In any case, the whole excersie seems rather pointless to me.
Even for the numbers that Marton presented, I was not sure it was
worth to rescan the descriptors, only to save a few kilobytes per
URB. It was 19KB total for bz#22182. In the event, we saved almost
all of it: the existing code only transfers 4170 bytes of 19200.
Now all this new code to save 4KB? No way.

-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ