The dm9601 driver expects to receive a single encapsulated ethernet
frame from the device in one URB transfer, and it provides an URB
buffer of length 1,522 to receive it. This is not a round multiple
of USB transfer packets.
The device in question [1] provides a stream of such frames and it
does not conveniently slice them up as the dm9601 driver expects. We
can end up with 1,536 (0x600) bytes returned by the device in response
to the URB request. This may include several encapsulated ethernet
frames, and/or fragments thereof.
It seems to me that the kernel 'Oops' arises because the dwc_otg driver
does not notice that the destination buffer is too small to receive the
full 1,536 bytes. Comparing dwc_otg's update_urb_state_xfer_comp with
dwc2's dwc2_update_urb_state is suggestive.
More details: https://github.com/raspberrypi/linux/issues/1045
All Credits to: https://github.com/mw9
Signed-off-by: Marian Hello <marian.hello@gmail.com>
Reviewed-by: Zoltan HERPAI <wigyori@uid0.hu>
Patch 610- is updated as check_entry helper was killed in 3.18.37
Fixes CVE-2016-5195 (dirtycow)
Compile-tested on ar71xx, mxs, sunxi, imx6
Runtime-tested on ar71xx (PB42)
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
The MR1750 must unset some bits in ETH_CFG which were set by u-boot to work
correctly under OpenWrt. But the global function
ath79_setup_qca955x_eth_cfg will not unset all of them to increase the
backward compatiblity with older mach-* files. A private (simplified)
version for MR1750 can be used instead.
Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
Backport of r49070
The MR900 must unset some bits in ETH_CFG which were set by u-boot to work
correctly under OpenWrt. But the global function
ath79_setup_qca955x_eth_cfg will not unset all of them to increase the
backward compatiblity with older mach-* files. A private (simplified)
version for MR900 can be used instead.
Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
Backport of r49069
The delays of PHY/MAC on the MR1750 are done by u-boot and OpenWrt in
different ways. u-boot only modifies the ETH_CFG of the QCA955x based on
the link speed. But OpenWrt can only modify the PHY delays based on the
link speed.
This can lead to communication problems when u-boot initializes the ETH_CFG
for a specific link speed (e.g. 10BASE-T) but then OpenWrt the sets the PHY
delays to an incompatible value.
Instead reset the ETH_CFG delay bits of the QCA955x to a specific value and
only rely on the AT803x PHY settings.
Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
Backport of r49031
The delays of PHY/MAC on the MR900 are done by u-boot and OpenWrt in
different ways. u-boot only modifies the ETH_CFG of the QCA955x based on
the link speed. But OpenWrt can only modify the PHY delays based on the
link speed.
This can lead to communication problems when u-boot initializes the ETH_CFG
for a specific link speed (e.g. 10BASE-T) but then OpenWrt the sets the PHY
delays to an incompatible value.
Instead reset the ETH_CFG delay bits of the QCA955x to a specific value and
only rely on the AT803x PHY settings.
Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
Backport of r49030
Some OpenWrt based firmwares like Gluon expect that a sysupgrade image
exists when a device firmware can be updated via sysupgrade. This image
wasn't created until now because OpenMesh devices use the same image for
factory and sysupgrade flash. Copying the image from *factory.bin to
*sysupgrade.bin is therefore enough to make the sysupgrade functionality
visible.
Reported-by: Matthias Schiffer <mschiffer@universe-factory.net>
Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
