linux-toradex.git/drivers, branch v3.4.77

hamradio/yam: fix info leak in ioctl

2014-01-15T23:27:11+00:00

[ Upstream commit 8e3fbf870481eb53b2d3a322d1fc395ad8b367ed ]

The yam_ioctl() code fails to initialise the cmd field
of the struct yamdrv_ioctl_cfg. Add an explicit memset(0)
before filling the structure to avoid the 4-byte info leak.

Signed-off-by: Salva Peiró 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

drivers/net/hamradio: Integer overflow in hdlcdrv_ioctl()

2014-01-15T23:27:11+00:00

[ Upstream commit e9db5c21d3646a6454fcd04938dd215ac3ab620a ]

The local variable 'bi' comes from userspace. If userspace passed a
large number to 'bi.data.calibrate', there would be an integer overflow
in the following line:
	s->hdlctx.calibrate = bi.data.calibrate * s->par.bitrate / 16;

Signed-off-by: Wenliang Fan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netvsc: don't flush peers notifying work during setting mtu

2014-01-15T23:27:11+00:00

[ Upstream commit 50dc875f2e6e2e04aed3b3033eb0ac99192d6d02 ]

There's a possible deadlock if we flush the peers notifying work during setting
mtu:

[   22.991149] ======================================================
[   22.991173] [ INFO: possible circular locking dependency detected ]
[   22.991198] 3.10.0-54.0.1.el7.x86_64.debug #1 Not tainted
[   22.991219] -------------------------------------------------------
[   22.991243] ip/974 is trying to acquire lock:
[   22.991261]  ((&(&net_device_ctx->dwork)->work)){+.+.+.}, at: [] flush_work+0x5/0x2e0
[   22.991307]
but task is already holding lock:
[   22.991330]  (rtnl_mutex){+.+.+.}, at: [] rtnetlink_rcv+0x1b/0x40
[   22.991367]
which lock already depends on the new lock.

[   22.991398]
the existing dependency chain (in reverse order) is:
[   22.991426]
-> #1 (rtnl_mutex){+.+.+.}:
[   22.991449]        [] __lock_acquire+0xb19/0x1260
[   22.991477]        [] lock_acquire+0xa2/0x1f0
[   22.991501]        [] mutex_lock_nested+0x89/0x4f0
[   22.991529]        [] rtnl_lock+0x17/0x20
[   22.991552]        [] netdev_notify_peers+0x12/0x30
[   22.991579]        [] netvsc_send_garp+0x22/0x30 [hv_netvsc]
[   22.991610]        [] process_one_work+0x211/0x6e0
[   22.991637]        [] worker_thread+0x11b/0x3a0
[   22.991663]        [] kthread+0xed/0x100
[   22.991686]        [] ret_from_fork+0x7c/0xb0
[   22.991715]
-> #0 ((&(&net_device_ctx->dwork)->work)){+.+.+.}:
[   22.991715]        [] check_prevs_add+0x967/0x970
[   22.991715]        [] __lock_acquire+0xb19/0x1260
[   22.991715]        [] lock_acquire+0xa2/0x1f0
[   22.991715]        [] flush_work+0x4e/0x2e0
[   22.991715]        [] __cancel_work_timer+0x95/0x130
[   22.991715]        [] cancel_delayed_work_sync+0x13/0x20
[   22.991715]        [] netvsc_change_mtu+0x84/0x200 [hv_netvsc]
[   22.991715]        [] dev_set_mtu+0x34/0x80
[   22.991715]        [] do_setlink+0x23a/0xa00
[   22.991715]        [] rtnl_newlink+0x394/0x5e0
[   22.991715]        [] rtnetlink_rcv_msg+0x9c/0x260
[   22.991715]        [] netlink_rcv_skb+0xa9/0xc0
[   22.991715]        [] rtnetlink_rcv+0x2a/0x40
[   22.991715]        [] netlink_unicast+0xdd/0x190
[   22.991715]        [] netlink_sendmsg+0x337/0x750
[   22.991715]        [] sock_sendmsg+0x99/0xd0
[   22.991715]        [] ___sys_sendmsg+0x39e/0x3b0
[   22.991715]        [] __sys_sendmsg+0x42/0x80
[   22.991715]        [] SyS_sendmsg+0x12/0x20
[   22.991715]        [] system_call_fastpath+0x16/0x1b

This is because we hold the rtnl_lock() before ndo_change_mtu() and try to flush
the work in netvsc_change_mtu(), in the mean time, netdev_notify_peers() may be
called from worker and also trying to hold the rtnl_lock. This will lead the
flush won't succeed forever. Solve this by not canceling and flushing the work,
this is safe because the transmission done by NETDEV_NOTIFY_PEERS was
synchronized with the netif_tx_disable() called by netvsc_change_mtu().

Reported-by: Yaju Cao 
Tested-by: Yaju Cao 
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Signed-off-by: Jason Wang 
Acked-by: Haiyang Zhang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tg3: Initialize REG_BASE_ADDR at PCI config offset 120 to 0

2014-01-15T23:27:11+00:00

[ Upstream commit 388d3335575f4c056dcf7138a30f1454e2145cd8 ]

The new tg3 driver leaves REG_BASE_ADDR (PCI config offset 120)
uninitialized. From power on reset this register may have garbage in it. The
Register Base Address register defines the device local address of a
register. The data pointed to by this location is read or written using
the Register Data register (PCI config offset 128). When REG_BASE_ADDR has
garbage any read or write of Register Data Register (PCI 128) will cause the
PCI bus to lock up. The TCO watchdog will fire and bring down the system.

Signed-off-by: Nat Gurumoorthy 
Acked-by: Michael Chan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvtap: signal truncated packets

2014-01-15T23:27:10+00:00

[ Upstream commit ce232ce01d61b184202bb185103d119820e1260c ]

macvtap_put_user() never return a value grater than iov length, this in fact
bypasses the truncated checking in macvtap_recvmsg(). Fix this by always
returning the size of packet plus the possible vlan header to let the trunca
checking work.

Cc: Vlad Yasevich 
Cc: Zhi Yong Wu 
Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
Acked-by: Vlad Yasevich 
Acked-by: Michael S. Tsirkin 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tun: update file current position

2014-01-15T23:27:10+00:00

[ Upstream commit d0b7da8afa079ffe018ab3e92879b7138977fc8f ]

Signed-off-by: Zhi Yong Wu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvtap: update file current position

2014-01-15T23:27:10+00:00

[ Upstream commit e6ebc7f16ca1434a334647aa56399c546be4e64b ]

Signed-off-by: Zhi Yong Wu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvtap: Do not double-count received packets

2014-01-15T23:27:10+00:00

[ Upstream commit 006da7b07bc4d3a7ffabad17cf639eec6849c9dc ]

Currently macvlan will count received packets after calling each
vlans receive handler.   Macvtap attempts to count the packet
yet again when the user reads the packet from the tap socket.
This code doesn't do this consistently either.  Remove the
counting from macvtap and let only macvlan count received
packets.

Signed-off-by: Vlad Yasevich 
Acked-by: Michael S. Tsirkin 
Acked-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: do not pretend FRAGLIST support

2014-01-15T23:27:10+00:00

[ Upstream commit 28e24c62ab3062e965ef1b3bcc244d50aee7fa85 ]

Few network drivers really supports frag_list : virtual drivers.

Some drivers wrongly advertise NETIF_F_FRAGLIST feature.

If skb with a frag_list is given to them, packet on the wire will be
corrupt.

Remove this flag, as core networking stack will make sure to
provide packets that can be sent without corruption.

Signed-off-by: Eric Dumazet 
Cc: Thadeu Lima de Souza Cascardo 
Cc: Anirudha Sarangi 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

hwmon: (w83l768ng) Fix fan speed control range

2014-01-08T17:42:12+00:00

commit 33a7ab91d509fa33b4bcd3ce0038cc80298050da upstream.

The W83L786NG stores the fan speed on 4 bits while the sysfs interface
uses a 0-255 range. Thus the driver should scale the user input down
to map it to the device range, and scale up the value read from the
device before presenting it to the user. The reserved register nibble
should be left unchanged.

Signed-off-by: Jean Delvare 
Reviewed-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman