Bug 1783552 (CVE-2019-19536)

Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1783553]

This was fixed for Fedora with the 5.2.9 stable kernel update.

It appears that the information leaks 'across the bus' not actually to the host, below is the code with not relevant sections snipped out.

static int pcan_usb_pro_drv_loaded(struct peak_usb_device *dev, int loaded)
{
   <snip> 
        buffer = kmalloc(PCAN_USBPRO_FCT_DRVLD_REQ_LEN, GFP_KERNEL);

        err = pcan_usb_pro_send_req(dev, PCAN_USBPRO_REQ_FCT,
                                    PCAN_USBPRO_FCT_DRVLD, buffer,
                                    PCAN_USBPRO_FCT_DRVLD_REQ_LEN);
        kfree(buffer);
}

So, the area for abuse is in pcan_usb_pro_send_req(), the req_addr arg.

pcan_usb_pro_send_req()
|  usb_control_msg()
|    usb_internal_control_msg()
|        usb_fill_control_urb() (enters struct urb->transfer_buffer here)
|    usb_start_wait_urb()
|    | usb_submit_urb()
|    |    usb_hcd_submit_urb()
|    |
|    usb_free_urb(urb); <-- freed here.|
|
| < kfreed here.
  
At this point its deep enough in the usb stack that I know that its not coming back as a value that is leaking to userspace, its going to be on the bus.


The attacker would need a device on the CANBUS (see https://en.wikipedia.org/wiki/CAN_bus ) to gather the information leak that is leaked.    This would mean that CVSSV3 scores would be scored as either physical or adjacent attack vectors. I'm going to choose adjacent as the attacker may wish to be on the network, listening for this 'information leak' while an end user plugs their device in.  

The CAN bus is a broadcast bus, all nodes on the network do get all packets of data sent by a node.  It appears that the data being leaked to the bus would be previous stack contents or userspace or kernel space data structures that previous occupied this area.

Just to be clear, this is -not- a normal TCP/IP network leak this is a -very- specific network type found on automotive and marine drive systems.

This flaw is rated as moderate, its an information leak that only happens once at device creation time, access methods of the information is quite difficult.

External References:

https://www.nxp.com/docs/en/reference-manual/BCANPSV2.pdf

Mitigation:

As the pcan_usb  module will be auto-loaded when required, its use can be disabled  by preventing the module from loading with the following instructions:

# echo "install pcan_usb /bin/true" >> /etc/modprobe.d/disable-pcan_usb.conf 
 
The system will need to be restarted if the module is loaded. In most circumstances, the pcan_usb kernel modules will be unable to be unloaded while any CANBUS interfaces are active and the protocol is in use.

If the system requires this module to work correctly, this mitigation may not be suitable.

If you need further assistance, see KCS article https://access.redhat.com/solutions/41278 or contact Red Hat Global Support Services.