linux-stable.git/drivers, branch v5.4.16

media: v4l2-ioctl.c: zero reserved fields for S/TRY_FMT

2020-01-29T15:45:33+00:00

commit ee8951e56c0f960b9621636603a822811cef3158 upstream.

v4l2_vbi_format, v4l2_sliced_vbi_format and v4l2_sdr_format
have a reserved array at the end that should be zeroed by drivers
as per the V4L2 spec. Older drivers often do not do this, so just
handle this in the core.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

libertas: Fix two buffer overflows at parsing bss descriptor

2020-01-29T15:45:33+00:00

commit e5e884b42639c74b5b57dc277909915c0aefc8bb upstream.

add_ie_rates() copys rates without checking the length
in bss descriptor from remote AP.when victim connects to
remote attacker, this may trigger buffer overflow.
lbs_ibss_join_existing() copys rates without checking the length
in bss descriptor from remote IBSS node.when victim connects to
remote attacker, this may trigger buffer overflow.
Fix them by putting the length check before performing copy.

This fix addresses CVE-2019-14896 and CVE-2019-14897.
This also fix build warning of mixed declarations and code.

Reported-by: kbuild test robot 
Signed-off-by: Wen Huang 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

net/sonic: Prevent tx watchdog timeout

2020-01-29T15:45:33+00:00

commit 686f85d71d095f1d26b807e23b0f0bfd22042c45 upstream.

Section 5.5.3.2 of the datasheet says,

    If FIFO Underrun, Byte Count Mismatch, Excessive Collision, or
    Excessive Deferral (if enabled) errors occur, transmission ceases.

In this situation, the chip asserts a TXER interrupt rather than TXDN.
But the handler for the TXDN is the only way that the transmit queue
gets restarted. Hence, an aborted transmission can result in a watchdog
timeout.

This problem can be reproduced on congested link, as that can result in
excessive transmitter collisions. Another way to reproduce this is with
a FIFO Underrun, which may be caused by DMA latency.

In event of a TXER interrupt, prevent a watchdog timeout by restarting
transmission.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/sonic: Fix CAM initialization

2020-01-29T15:45:32+00:00

commit 772f66421d5aa0b9f256056f513bbc38ac132271 upstream.

Section 4.3.1 of the datasheet says,

    This bit [TXP] must not be set if a Load CAM operation is in
    progress (LCAM is set). The SONIC will lock up if both bits are
    set simultaneously.

Testing has shown that the driver sometimes attempts to set LCAM
while TXP is set. Avoid this by waiting for command completion
before and after giving the LCAM command.

After issuing the Load CAM command, poll for !SONIC_CR_LCAM rather than
SONIC_INT_LCD, because the SONIC_CR_TXP bit can't be used until
!SONIC_CR_LCAM.

When in reset mode, take the opportunity to reset the CAM Enable
register.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/sonic: Fix command register usage

2020-01-29T15:45:32+00:00

commit 27e0c31c5f27c1d1a1d9d135c123069f60dcf97b upstream.

There are several issues relating to command register usage during
chip initialization.

Firstly, the SONIC sometimes comes out of software reset with the
Start Timer bit set. This gets logged as,

    macsonic macsonic eth0: sonic_init: status=24, i=101

Avoid this by giving the Stop Timer command earlier than later.

Secondly, the loop that waits for the Read RRA command to complete has
the break condition inverted. That's why the for loop iterates until
its termination condition. Call the helper for this instead.

Finally, give the Receiver Enable command after clearing interrupts,
not before, to avoid the possibility of losing an interrupt.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/sonic: Quiesce SONIC before re-initializing descriptor memory

2020-01-29T15:45:32+00:00

commit 3f4b7e6a2be982fd8820a2b54d46dd9c351db899 upstream.

Make sure the SONIC's DMA engine is idle before altering the transmit
and receive descriptors. Add a helper for this as it will be needed
again.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/sonic: Fix receive buffer replenishment

2020-01-29T15:45:32+00:00

commit 89ba879e95582d3bba55081e45b5409e883312ca upstream.

As soon as the driver is finished with a receive buffer it allocs a new
one and overwrites the corresponding RRA entry with a new buffer pointer.

Problem is, the buffer pointer is split across two word-sized registers.
It can't be updated in one atomic store. So this operation races with the
chip while it stores received packets and advances its RRP register.
This could result in memory corruption by a DMA write.

Avoid this problem by adding buffers only at the location given by the
RWP register, in accordance with the National Semiconductor datasheet.

Re-factor this code into separate functions to calculate a RRA pointer
and to update the RWP.

Fixes: efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update")
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/sonic: Improve receive descriptor status flag check

2020-01-29T15:45:32+00:00

commit 94b166349503957079ef5e7d6f667f157aea014a upstream.

After sonic_tx_timeout() calls sonic_init(), it can happen that
sonic_rx() will subsequently encounter a receive descriptor with no
flags set. Remove the comment that says that this can't happen.

When giving a receive descriptor to the SONIC, clear the descriptor
status field. That way, any rx descriptor with flags set can only be
a newly received packet.

Don't process a descriptor without the LPKT bit set. The buffer is
still in use by the SONIC.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/sonic: Avoid needless receive descriptor EOL flag updates

2020-01-29T15:45:32+00:00

commit eaabfd19b2c787bbe88dc32424b9a43d67293422 upstream.

The while loop in sonic_rx() traverses the rx descriptor ring. It stops
when it reaches a descriptor that the SONIC has not used. Each iteration
advances the EOL flag so the SONIC can keep using more descriptors.
Therefore, the while loop has no definite termination condition.

The algorithm described in the National Semiconductor literature is quite
different. It consumes descriptors up to the one with its EOL flag set
(which will also have its "in use" flag set). All freed descriptors are
then returned to the ring at once, by adjusting the EOL flags (and link
pointers).

Adopt the algorithm from datasheet as it's simpler, terminates quickly
and avoids a lot of pointless descriptor EOL flag changes.

Fixes: efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update")
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/sonic: Fix receive buffer handling

2020-01-29T15:45:32+00:00

commit 9e311820f67e740f4fb8dcb82b4c4b5b05bdd1a5 upstream.

The SONIC can sometimes advance its rx buffer pointer (RRP register)
without advancing its rx descriptor pointer (CRDA register). As a result
the index of the current rx descriptor may not equal that of the current
rx buffer. The driver mistakenly assumes that they are always equal.
This assumption leads to incorrect packet lengths and possible packet
duplication. Avoid this by calling a new function to locate the buffer
corresponding to a given descriptor.

Fixes: efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update")
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman