Re: [PATCH] usbnet: ipheth: fix potential recvmsg bug and recvmsg bug 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2018-11-23 at 13:51 +0100, Bernd Eckstein wrote: > This causes the following problems: > - double free of the skb or potential memory leak > - in dmesg: 'recvmsg bug' and 'recvmsg bug 2' and eventually > general protection fault For what it's worth, Bernd contacted me because it looks like this was the cause of https://lore.kernel.org/lkml/20180605085450.ga3...@scapa.corsac.net/ I wanted to try Bernd patch, unfortunately I wasn't able to reproduce the freezes on more recent kernels, so right now I can't add a Tested-By, but I'd be happy to be kept on CC. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlv3+4YACgkQ3rYcyPpX RFuuoQgAhJHvzpl1yr7ZM215DviNj8Q/n7WpiWSk6ik5Ts8n4qsgIRcXojhEPfkw KAmpJ7G1zRgxRtZayiKLUl7RE3uWNOjTph3pzztBmMI+P7C/R4pVdZeRlandGsju YH6G32u+BB55tJw/TYrahlG3Ni0HNDoL+QfgJJno6/dr9V+YFr+opTCuDchaBHeJ acVsogUkyclvAutHt3UMjiDvVB12mW6IFz997y1Fv3JMT9HTQrDT9VdMUSr2WC5s rb9ONoim1ADDgTBN10mbPWZ80aooR8GtNEGpFa2EL0vPdNVlqyZqV46hYbLuZZ42 tMF3AD6hrQqxitCS3QGJpWjFFscFMA== =OkrF -END PGP SIGNATURE-
Re: Page allocation failure (order 7) in UAS code
On ven., 2016-03-04 at 08:18 +0100, Hans de Goede wrote: > Thanks for testing, there shouldn't be any side-effects, I'll turn this into > a proper patch, add a: > > Reported-and-tested-by: Yves-Alexis Perez > > line to the comit msg and submit this upstream. > > Thanks, I guess it can also be CC: stable@ since it started in 4.4. Regards, -- Yves-Alexis -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Page allocation failure (order 7) in UAS code
On mar., 2016-03-01 at 11:49 +0100, Hans de Goede wrote: > Hi, > > On 01-03-16 10:42, Yves-Alexis Perez wrote: > > > > Hi, > > > > [sorry if this is not the right point for reporting bugs, I took the email > > addresses from MAINTAINERS but please point me to the correct place if > > needed] > > > > I have an external USB drive (Samsung M3), which apparently uses the UAS > > code. > > Starting with 4.4 (from Debian sid, I could retry with vanilla if needed), > > I > > can't mount the drive anymore after a while (few hours/days uptime). Just > > plugging the disk, I get page allocation failure in kernel logs: > Can you try building a kernel with the following line in > drivers/usb/storage/uas.c : > > .can_queue = 65536, /* Is there a limit on the _host_ ? */ > > (around line 815) Replaced with > > .can_queue = MAX_CMNDS, > > That should help as MAX_CMNDS is 256, so claiming that we can queue more > is not helpful, and that likely is what is causing this quite high order > alloc. After a few days, it seems that it does work fine, although I can't say anything about sides effects. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Page allocation failure (order 7) in UAS code
On mar., 2016-03-01 at 11:49 +0100, Hans de Goede wrote: > Can you try building a kernel with the following line in > drivers/usb/storage/uas.c : > > .can_queue = 65536, /* Is there a limit on the _host_ ? */ > > (around line 815) Replaced with > > .can_queue = MAX_CMNDS, > > That should help as MAX_CMNDS is 256, so claiming that we can queue more > is not helpful, and that likely is what is causing this quite high order > alloc. Hi, I've rebuilt a 4.4.3 + above patch. I'll report back in few hours to see if I can still reproduce. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Page allocation failure (order 7) in UAS code
Hi, [sorry if this is not the right point for reporting bugs, I took the email addresses from MAINTAINERS but please point me to the correct place if needed] I have an external USB drive (Samsung M3), which apparently uses the UAS code. Starting with 4.4 (from Debian sid, I could retry with vanilla if needed), I can't mount the drive anymore after a while (few hours/days uptime). Just plugging the disk, I get page allocation failure in kernel logs: Feb 22 10:57:56 scapa kernel: [26557.268872] usb 2-2: new SuperSpeed USB device number 3 using xhci_hcd Feb 22 10:57:56 scapa kernel: [26557.285884] usb 2-2: New USB device found, idVendor=04e8, idProduct=61b6 Feb 22 10:57:56 scapa kernel: [26557.285888] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Feb 22 10:57:56 scapa kernel: [26557.285891] usb 2-2: Product: Samsung M3 Portable Feb 22 10:57:56 scapa kernel: [26557.285893] usb 2-2: Manufacturer: Samsung M3 Portable Feb 22 10:57:56 scapa kernel: [26557.285895] usb 2-2: SerialNumber: 826C7DFB1367 Feb 22 10:57:56 scapa kernel: [26557.293693] scsi host4: uas Feb 22 10:57:56 scapa kernel: [26557.293707] kworker/0:0: page allocation failure: order:7, mode:0x2204020 Feb 22 10:57:56 scapa kernel: [26557.293711] CPU: 0 PID: 11015 Comm: kworker/0:0 Tainted: GW 4.4.0-1-amd64 #1 Debian 4.4.2-3~a.test Feb 22 10:57:56 scapa kernel: [26557.293713] Hardware name: LENOVO 20CMCTO1WW/20CMCTO1WW, BIOS N10ET41W (1.20 ) 01/19/2016 Feb 22 10:57:56 scapa kernel: [26557.293724] Workqueue: usb_hub_wq hub_event [usbcore] Feb 22 10:57:56 scapa kernel: [26557.293727] c0207f69 812e7679 02204020 Feb 22 10:57:56 scapa kernel: [26557.293730] 8116b23a 0001c0207f69 88024dffbb20 Feb 22 10:57:56 scapa kernel: [26557.293733] 810b475e 0001020c8220 c0207f69 0046 Feb 22 10:57:56 scapa kernel: [26557.293736] Call Trace: Feb 22 10:57:56 scapa kernel: [26557.293741] [] ? dump_stack+0x40/0x57 Feb 22 10:57:56 scapa kernel: [26557.293745] [] ? warn_alloc_failed+0xfa/0x150 Feb 22 10:57:56 scapa kernel: [26557.293749] [] ? __wake_up_common+0x4e/0x90 Feb 22 10:57:56 scapa kernel: [26557.293752] [] ? __alloc_pages_nodemask+0x306/0xb70 Feb 22 10:57:56 scapa kernel: [26557.293757] [] ? kmem_getpages+0x51/0xf0 Feb 22 10:57:56 scapa kernel: [26557.293759] [] ? fallback_alloc+0x145/0x1f0 Feb 22 10:57:56 scapa kernel: [26557.293765] [] ? init_tag_map+0x38/0xb0 Feb 22 10:57:56 scapa kernel: [26557.293768] [] ? __kmalloc+0x17f/0x1c0 Feb 22 10:57:56 scapa kernel: [26557.293771] [] ? init_tag_map+0x38/0xb0 Feb 22 10:57:56 scapa kernel: [26557.293774] [] ? __blk_queue_init_tags+0x40/0x80 Feb 22 10:57:56 scapa kernel: [26557.293781] [] ? scsi_add_host_with_dma+0x7b/0x2f0 [scsi_mod] Feb 22 10:57:56 scapa kernel: [26557.293785] [] ? uas_probe+0x41a/0x560 [uas] Feb 22 10:57:56 scapa kernel: [26557.293796] [] ? usb_probe_interface+0x1b3/0x300 [usbcore] Feb 22 10:57:56 scapa kernel: [26557.293801] [] ? driver_probe_device+0x212/0x480 Feb 22 10:57:56 scapa kernel: [26557.293803] [] ? __driver_attach+0x80/0x80 Feb 22 10:57:56 scapa kernel: [26557.293806] [] ? bus_for_each_drv+0x62/0xb0 Feb 22 10:57:56 scapa kernel: [26557.293809] [] ? __device_attach+0xd8/0x160 Feb 22 10:57:56 scapa kernel: [26557.293811] [] ? bus_probe_device+0x87/0xa0 Feb 22 10:57:56 scapa kernel: [26557.293814] [] ? device_add+0x3f5/0x660 Feb 22 10:57:56 scapa kernel: [26557.293823] [] ? usb_set_configuration+0x51b/0x8f0 [usbcore] Feb 22 10:57:56 scapa kernel: [26557.293835] [] ? generic_probe+0x28/0x80 [usbcore] Feb 22 10:57:56 scapa kernel: [26557.293838] [] ? driver_probe_device+0x212/0x480 Feb 22 10:57:56 scapa kernel: [26557.293840] [] ? __driver_attach+0x80/0x80 Feb 22 10:57:56 scapa kernel: [26557.293842] [] ? bus_for_each_drv+0x62/0xb0 Feb 22 10:57:56 scapa kernel: [26557.293845] [] ? __device_attach+0xd8/0x160 Feb 22 10:57:56 scapa kernel: [26557.293847] [] ? bus_probe_device+0x87/0xa0 Feb 22 10:57:56 scapa kernel: [26557.293850] [] ? device_add+0x3f5/0x660 Feb 22 10:57:56 scapa kernel: [26557.293857] [] ? usb_new_device+0x265/0x490 [usbcore] Feb 22 10:57:56 scapa kernel: [26557.293864] [] ? hub_event+0xfb3/0x14f0 [usbcore] Feb 22 10:57:56 scapa kernel: [26557.293868] [] ? process_one_work+0x19f/0x3d0 Feb 22 10:57:56 scapa kernel: [26557.293871] [] ? worker_thread+0x4d/0x450 Feb 22 10:57:56 scapa kernel: [26557.293873] [] ? process_one_work+0x3d0/0x3d0 Feb 22 10:57:56 scapa kernel: [26557.293876] [] ? kthread+0xcd/0xf0 Feb 22 10:57:56 scapa kernel: [26557.293879] [] ? kthread_create_on_node+0x190/0x190 Feb 22 10:57:56 scapa kernel: [26557.293883] [] ? ret_from_fork+0x3f/0x70 Feb 22 10:57:56 scapa kernel: [26557.293886] [] ? kthread_create_on_node+0x190/0x190 Feb 22 10:57:56 scapa kernel: [26557.293888] Mem-Info: Feb 22 10:57:56 scapa kernel: [26557.293892] active_anon:1
Re: [oss-security] BadUSB discussion
On ven., 2014-08-08 at 18:50 -0400, Alan Stern wrote: > On Sat, 9 Aug 2014, Yves-Alexis Perez wrote: > > > On ven., 2014-08-08 at 18:26 -0400, Alan Stern wrote: > > > I'm not sure what you mean. You can toggle these values at any time, > > > but toggling them may not accomplish anything useful. What do you > > > want > > > to accomplish? > > > > The point would be to prevent new usb device to be plugged while a > > system is locked (or no one is logged in). > > > > Grsecurity has something like that using a custom sysctl, but Greg > > comment on the oss-sec made me thing it might have already been possible > > in mainline. > > Well, you can't prevent new devices from being plugged in -- not unless > you do something pretty drastic, like filling the USB ports with glue. > :-) Yeah, that's not really what I intended :) > But you _can_ prevent new devices from being authorized. You just > do what I said earlier > : write > > echo 0 >/sys/bus/usb/devices/usbN/authorized_default > > for each N corresponding to an existing USB bus. Ok, I was confused and used usbN/authorized instead of authorized_default, sorry for the noise. > > > > Note that in addition to changing the default values, you can change > > > the actual authorization value for an existing device at any time by > > > writing to the device's "authorized" sysfs file. > > > > Yeah but that doesn't really work, > > What do you mean? It really _does_ work. If you write > > echo 0 >/sys/bus/usb/devices/1-3/authorized > > then device 3 on bus 1 really _will_ be deauthorized. > Indeed, that works. > > If you write "echo 0 >/sys/bus/usb/devices/usb1/authorized_default", it > will not deauthorize any currently plugged devices. All it will do is > change the default authorization value assigned to new devices when > they are plugged in. Ok, it does seem to work. Two things, though. - before doing anything, I have: grep . /sys/bus/usb/devices/*/authorized_default /sys/bus/usb/devices/usb1/authorized_default:1 /sys/bus/usb/devices/usb2/authorized_default:1 shouldn't it be -1? After putting 0 there, unplugging my USB mouse and re-plugging it, the mouse doesn't work, still gets enumerated: Aug 9 09:06:24 scapa kernel: [33176.030104] usb 1-1.5.1: new low-speed USB device number 12 using ehci-pci Aug 9 09:06:24 scapa kernel: [33176.143702] usb 1-1.5.1: New USB device found, idVendor=046d, idProduct=c00c Aug 9 09:06:24 scapa kernel: [33176.143709] usb 1-1.5.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Aug 9 09:06:24 scapa kernel: [33176.143713] usb 1-1.5.1: Product: USB Optical Mouse Aug 9 09:06:24 scapa kernel: [33176.143716] usb 1-1.5.1: Manufacturer: Logitech but it's not handled by the input driver like usually: Aug 9 09:06:50 scapa kernel: [33202.016667] input: Logitech USB Optical Mouse as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/0003:046D:C00C.0004/input/input17 Aug 9 09:06:50 scapa kernel: [33202.016975] hid-generic 0003:046D:C00C.0004: input,hidraw0: USB HID v1.10 Mouse [Logitech USB Optical Mouse] on usb-:00:1a.0-1.5.1/input0 Anyway, thanks for the tip, and again sorry for the noise. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: [oss-security] BadUSB discussion
On ven., 2014-08-08 at 18:26 -0400, Alan Stern wrote: > I'm not sure what you mean. You can toggle these values at any time, > but toggling them may not accomplish anything useful. What do you > want > to accomplish? The point would be to prevent new usb device to be plugged while a system is locked (or no one is logged in). Grsecurity has something like that using a custom sysctl, but Greg comment on the oss-sec made me thing it might have already been possible in mainline. > > Note that in addition to changing the default values, you can change > the actual authorization value for an existing device at any time by > writing to the device's "authorized" sysfs file. Yeah but that doesn't really work, because one would need to disable that at the bus level (for every bus), and that would also disable the currently plugged devices. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: [oss-security] BadUSB discussion
On ven., 2014-08-08 at 18:17 -0400, Alan Stern wrote: > The authorized_default module parameter affects USB buses when they > are > discovered and registered; after that it has no effect. Therefore to > accomplish what you want, you need to put > "usbcore.authorized_default=0" in the kernel's boot command line. > > Alternatively, you can change the default authorization value for a > particular bus after it has been created, by writing to the > authorized_default sysfs file for the bus's root hub. For example, > > echo 0 >/sys/bus/usb/devices/usb1/authorized_default > > will set the default value for new devices on bus 1 to 0. Thanks for your answer. So that confirms it's not possible to toggle that value depending on a platform state (for example if the session is locked). Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: [oss-security] BadUSB discussion
On ven., 2014-08-08 at 14:36 -0700, Greg KH wrote: > On Fri, Aug 08, 2014 at 11:27:06PM +0200, Yves-Alexis Perez wrote: > > On ven., 2014-08-08 at 14:20 -0700, Greg KH wrote: > > > > Actually, since it's a module parameter, it doesn't seem possible to > > > > toggle it without reloading the module (or rebooting if it's > > > builtin). > > > > So it might not be that easy to do the locking part. > > > > > > echo "0" > /sys/module/usbcore/parameters/authorized_default > > > > I did that, but unplugging/replugging my mouse still works after that. > > Hm, not good, take it to the linux-usb@vger.kernel.org mailing list and > we can debug it there. > Ok. So, linux-usb people, a bit of context. Following the BadUSB circus [1] there was a thread on oss-sec about that [2], where Greg mentionned the usbcore 'authorized_default' parameter. I thought it would be a good idea to toggle that parameter when locking my laptop, so I tried to echo to the above file, but it doesn't seem to prevent me plugging my mouse or an usb key. I'm running Debian sid, current running kernel is the Debian one: Linux scapa 3.14-2-amd64 #1 SMP Debian 3.14.13-2 (2014-07-24) x86_64 GNU/Linux Ben Hutching uploaded 3.14.15-1 so I'll try it asap, but I can also build a 3.16 just to check. Regards, [1] https://srlabs.de/badusb/ [2] http://www.openwall.com/lists/oss-security/2014/08/08/1 -- Yves-Alexis signature.asc Description: This is a digitally signed message part
