4.9.308-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 4.9.308-rc1 review
This is the start of the stable review cycle for the 4.9.308 release. There are 16 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 23 Mar 2022 13:32:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.308-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.9.308-rc1
Pavel Skripkin <[email protected]>
Input: aiptek - properly check endpoint type
Alan Stern <[email protected]>
usb: gadget: Fix use-after-free bug by not setting udc->dev.driver
Dan Carpenter <[email protected]>
usb: gadget: rndis: prevent integer overflow in rndis_set_response()
Jiasheng Jiang <[email protected]>
atm: eni: Add check for dma_map_single
Eric Dumazet <[email protected]>
net/packet: fix slab-out-of-bounds access in packet_recvmsg()
Lucas Wei <[email protected]>
fs: sysfs_emit: Remove PAGE_SIZE alignment check
Chengming Zhou <[email protected]>
kselftest/vm: fix tests build with old libc
Niels Dossche <[email protected]>
sfc: extend the locking on mcdi->seqno
Eric Dumazet <[email protected]>
tcp: make tcp_read_sock() more robust
Sreeramya Soratkal <[email protected]>
nl80211: Update bss channel on channel switch for P2P_CLIENT
Jia-Ju Bai <[email protected]>
atm: firestream: check the return value of ioremap() in fs_init()
Lad Prabhakar <[email protected]>
can: rcar_canfd: rcar_canfd_channel_probe(): register the CAN device when fully ready
Julian Braha <[email protected]>
ARM: 9178/1: fix unmet dependency on BITREVERSE for HAVE_ARCH_BITREVERSE
Alexander Lobakin <[email protected]>
MIPS: smp: fill in sibling and core maps earlier
Corentin Labbe <[email protected]>
ARM: dts: rockchip: fix a typo on rk3288 crypto-controller
Yan Yan <[email protected]>
xfrm: Fix xfrm migrate issues when address family changes
-------------
Diffstat:
Makefile | 4 ++-- arch/arm/boot/dts/rk3288.dtsi | 2 +- arch/mips/kernel/smp.c | 6 +++--- drivers/atm/eni.c | 2 ++ drivers/atm/firestream.c | 2 ++ drivers/input/tablet/aiptek.c | 10 ++++------ drivers/net/can/rcar/rcar_canfd.c | 6 +++--- drivers/net/ethernet/sfc/mcdi.c | 2 +- drivers/usb/gadget/function/rndis.c | 1 + drivers/usb/gadget/udc/core.c | 3 --- fs/sysfs/file.c | 3 +-- lib/Kconfig | 1 - net/ipv4/tcp.c | 10 ++++++---- net/packet/af_packet.c | 11 ++++++++++- net/wireless/nl80211.c | 3 ++- net/xfrm/xfrm_state.c | 8 +++++--- tools/testing/selftests/vm/userfaultfd.c | 1 + 17 files changed, 44 insertions(+), 31 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/16 xfrm: Fix xfrm migrate issues when address family changes
From: Yan Yan <[email protected]>
[ Upstream commit e03c3bba351f99ad932e8f06baa9da1afc418e02 ]
xfrm_migrate cannot handle address family change of an xfrm_state. The symptons are the xfrm_state will be migrated to a wrong address, and sending as well as receiving packets wil be broken.
This commit fixes it by breaking the original xfrm_state_clone method into two steps so as to update the props.family before running xfrm_init_state. As the result, xfrm_state's inner mode, outer mode, type and IP header length in xfrm_state_migrate can be updated with the new address family.
Tested with additions to Android's kernel unit test suite:
https://android-review.googlesource.com/c/kernel/tests/+/1885354
--- net/xfrm/xfrm_state.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
net/xfrm/xfrm_state.c +5 -3
@@ -1238,9 +1238,6 @@ static struct xfrm_state *xfrm_state_clone(struct xfrm_state *orig)memcpy (&x->mark, &orig->mark,sizeof (x->mark)); -if (xfrm_init_state (x) <0 ) - goto error; - x->props.flags = orig->props.flags; x->props.extra_flags = orig->props.extra_flags;
@@ -1317,6 +1314,11 @@ struct xfrm_state *xfrm_state_migrate(struct xfrm_state *x,if (!xc)return NULL ; + xc->props.family = m->new_family; + +if (xfrm_init_state (xc) <0 ) + goto error; +memcpy (&xc->id.daddr, &m->new_daddr,sizeof (xc->id.daddr));memcpy (&xc->props.saddr, &m->new_saddr,sizeof (xc->props.saddr));
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 2/16 ARM: dts: rockchip: fix a typo on rk3288 crypto-controller
In reply to Greg Kroah-HartmanFrom: Corentin Labbe <[email protected]>
[ Upstream commit 3916c3619599a3970d3e6f98fb430b7c46266ada ]
crypto-controller had a typo, fix it.
In the same time, rename it to just crypto
--- arch/arm/boot/dts/rk3288.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/rk3288.dtsi +1 -1
@@ -918,7 +918,7 @@ status = "disabled"; }; - crypto: cypto-controller@ff8a0000 { + crypto: crypto@ff8a0000 { compatible = "rockchip,rk3288-crypto"; reg = <0xff8a0000 0x4000>; interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 3/16 MIPS: smp: fill in sibling and core maps earlier
In reply to Greg Kroah-HartmanFrom: Alexander Lobakin <[email protected]>
[ Upstream commit f2703def339c793674010cc9f01bfe4980231808 ]
After enabling CONFIG_SCHED_CORE (landed during 5.14 cycle), 2-core 2-thread-per-core interAptiv (CPS-driven) started emitting the following:
[ 0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi)) [ 0.048183] ------------[ cut here ]------------ [ 0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240 [ 0.048220] Modules linked in: [ 0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f [ 0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1 [ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000 [ 0.048307] 00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000 [ 0.048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34 [ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933 [ 0.048389] ... [ 0.048396] Call Trace: [ 0.048399] [<8105a7bc>] show_stack+0x3c/0x140 [ 0.048424] [<8131c2a0>] dump_stack_lvl+0x60/0x80 [ 0.048440] [<8108b5c0>] __warn+0xc0/0xf4 [ 0.048454] [<8108b658>] warn_slowpath_fmt+0x64/0x10c [ 0.048467] [<810bd418>] sched_core_cpu_starting+0x198/0x240 [ 0.048483] [<810c6514>] sched_cpu_starting+0x14/0x80 [ 0.048497] [<8108c0f8>] cpuhp_invoke_callback_range+0x78/0x140 [ 0.048510] [<8108d914>] notify_cpu_starting+0x94/0x140 [ 0.048523] [<8106593c>] start_secondary+0xbc/0x280 [ 0.048539] [ 0.048543] ---[ end trace 0000000000000000 ]--- [ 0.048636] Synchronize counters for CPU 1: done.
...for each but CPU 0/boot.
Basic debug printks right before the mentioned line say:
[ 0.048170] CPU: 1, smt_mask:
So smt_mask, which is sibling mask obviously, is empty when entering the function.
This is critical, as sched_core_cpu_starting() calculates core-scheduling parameters only once per CPU start, and it's crucial to have all the parameters filled in at that moment (at least it uses cpu_smt_mask() which in fact is &cpu_sibling_map[cpu] on MIPS).
A bit of debugging led me to that set_cpu_sibling_map() performing the actual map calculation, was being invocated after notify_cpu_start(), and exactly the latter function starts CPU HP callback round (sched_core_cpu_starting() is basically a CPU HP callback).
While the flow is same on ARM64 (maps after the notifier, although before calling set_cpu_online()), x86 started calculating sibling maps earlier than starting the CPU HP callbacks in Linux 4.14 (see
[0] for the reference). Neither me nor my brief tests couldn't find any potential caveats in calculating the maps right after performing delay calibration, but the WARN splat is now gone.
The very same debug prints now yield exactly what I expected from them:
[ 0.048433] CPU: 1, smt_mask: 0-1
[0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef
--- arch/mips/kernel/smp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
arch/mips/kernel/smp.c +3 -3
@@ -369,6 +369,9 @@ asmlinkage void start_secondary(void) cpu =smp_processor_id (); cpu_data[cpu].udelay_val = loops_per_jiffy; +set_cpu_sibling_map (cpu); +set_cpu_core_map (cpu); +cpumask_set_cpu (cpu, &cpu_coherent_mask);notify_cpu_starting (cpu);
@@ -380,9 +383,6 @@ asmlinkage void start_secondary(void)/* The CPU is running and counters synchronised, now mark it online */ set_cpu_online (cpu, true); -set_cpu_sibling_map (cpu); -set_cpu_core_map (cpu); -calculate_cpu_foreign_map ();/*
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 4/16 ARM: 9178/1: fix unmet dependency on BITREVERSE for HAVE_ARCH_BITREVERSE
In reply to Greg Kroah-HartmanFrom: Julian Braha <[email protected]>
[ Upstream commit 11c57c3ba94da74c3446924260e34e0b1950b5d7 ]
Resending this to properly add it to the patch tracker - thanks for letting me know, Arnd :)
When ARM is enabled, and BITREVERSE is disabled,Kbuild gives the following warning:
WARNING: unmet direct dependencies detected for HAVE_ARCH_BITREVERSE
Depends on [n]: BITREVERSE [=n]
Selected by [y]:
- ARM [=y] && (CPU_32v7M [=n] || CPU_32v7 [=y]) && !CPU_32v6 [=n]
This is because ARM selects HAVE_ARCH_BITREVERSE
without selecting BITREVERSE, despiteHAVE_ARCH_BITREVERSE depending on BITREVERSE.
This unmet dependency bug was found by Kismet,
a static analysis tool for Kconfig. Please advise if this is not the appropriate solution.
--- lib/Kconfig | 1 - 1 file changed, 1 deletion(-)
lib/Kconfig +0 -1
@@ -16,7 +16,6 @@ config BITREVERSE config HAVE_ARCH_BITREVERSE bool default n - depends on BITREVERSE help This option enables the use of hardware bit-reversal instructions on architectures which support such operations.
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 5/16 can: rcar_canfd: rcar_canfd_channel_probe(): register the CAN device when fully ready
In reply to Greg Kroah-HartmanFrom: Lad Prabhakar <[email protected]>
[ Upstream commit c5048a7b2c23ab589f3476a783bd586b663eda5b ]
Register the CAN device only when all the necessary initialization is completed. This patch makes sure all the data structures and locks are initialized before registering the CAN device.
--- drivers/net/can/rcar/rcar_canfd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/net/can/rcar/rcar_canfd.c +3 -3
@@ -1601,15 +1601,15 @@ static int rcar_canfd_channel_probe(struct rcar_canfd_global *gpriv, u32 ch,netif_napi_add (ndev, &priv->napi, rcar_canfd_rx_poll,RCANFD_NAPI_WEIGHT ); +spin_lock_init (&priv->tx_lock); +devm_can_led_init (ndev); + gpriv->ch[priv->channel] = priv; err =register_candev (ndev);if (err) {dev_err (&pdev->dev,"register_candev() failed, error %d\n" , err); goto fail_candev; } -spin_lock_init (&priv->tx_lock); -devm_can_led_init (ndev); - gpriv->ch[priv->channel] = priv;dev_info (&pdev->dev,"device registered (channel %u)\n" , priv->channel);return 0 ;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 6/16 atm: firestream: check the return value of ioremap() in fs_init()
In reply to Greg Kroah-HartmanFrom: Jia-Ju Bai <[email protected]>
[ Upstream commit d4e26aaea7f82ba884dcb4acfe689406bc092dc3 ]
The function ioremap() in fs_init() can fail, so its return value should be checked.
--- drivers/atm/firestream.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/atm/firestream.c +2 -0
@@ -1692,6 +1692,8 @@ static int fs_init(struct fs_dev *dev) dev->hw_base =pci_resource_start (pci_dev,0 ); dev->base =ioremap (dev->hw_base,0x1000 ); +if (!dev->base) +return 1 ;reset_chip (dev);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 7/16 nl80211: Update bss channel on channel switch for P2P_CLIENT
In reply to Greg Kroah-HartmanFrom: Sreeramya Soratkal <[email protected]>
[ Upstream commit e50b88c4f076242358b66ddb67482b96947438f2 ]
The wdev channel information is updated post channel switch only for the station mode and not for the other modes. Due to this, the P2P client still points to the old value though it moved to the new channel when the channel change is induced from the P2P GO.
Update the bss channel after CSA channel switch completion for P2P client interface as well.
--- net/wireless/nl80211.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/wireless/nl80211.c +2 -1
@@ -14068,7 +14068,8 @@ void cfg80211_ch_switch_notify(struct net_device *dev, wdev->chandef = *chandef; wdev->preset_chandef = *chandef; -if (wdev->iftype ==NL80211_IFTYPE_STATION && +if ((wdev->iftype ==NL80211_IFTYPE_STATION || + wdev->iftype ==NL80211_IFTYPE_P2P_CLIENT ) && !WARN_ON (!wdev->current_bss)) wdev->current_bss->pub.channel = chandef->chan;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 8/16 tcp: make tcp_read_sock() more robust
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
[ Upstream commit e3d5ea2c011ecb16fb94c56a659364e6b30fac94 ]
If recv_actor() returns an incorrect value, tcp_read_sock() might loop forever.
Instead, issue a one time warning and make sure to make progress.
--- net/ipv4/tcp.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
net/ipv4/tcp.c +6 -4
@@ -1561,11 +1561,13 @@ int tcp_read_sock(struct sock *sk, read_descriptor_t *desc,if (!copied) copied = used;break ; - }else if (used <= len) { - seq += used; - copied += used; - offset += used; } +if (WARN_ON_ONCE (used > len)) + used = len; + seq += used; + copied += used; + offset += used; +/* If recv_actor drops the lock (e.g. TCP splice * receive) the skb pointer might be invalid when * getting here: tcp_collapse might have deleted it
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 9/16 sfc: extend the locking on mcdi->seqno
In reply to Greg Kroah-HartmanFrom: Niels Dossche <[email protected]>
[ Upstream commit f1fb205efb0ccca55626fd4ef38570dd16b44719 ]
seqno could be read as a stale value outside of the lock. The lock is already acquired to protect the modification of seqno against a possible race condition. Place the reading of this value also inside this locking to protect it against a possible race condition.
--- drivers/net/ethernet/sfc/mcdi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/sfc/mcdi.c +1 -1
@@ -162,9 +162,9 @@ static void efx_mcdi_send_request(struct efx_nic *efx, unsigned cmd,/* Serialise with efx_mcdi_ev_cpl() and efx_mcdi_ev_death() */ spin_lock_bh (&mcdi->iface_lock); ++mcdi->seqno; + seqno = mcdi->seqno &SEQ_MASK ;spin_unlock_bh (&mcdi->iface_lock); - seqno = mcdi->seqno &SEQ_MASK ; xflags =0 ;if (mcdi->mode ==MCDI_MODE_EVENTS ) xflags |=MCDI_HEADER_XFLAGS_EVREQ ;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 10/16 kselftest/vm: fix tests build with old libc
In reply to Greg Kroah-HartmanFrom: Chengming Zhou <[email protected]>
[ Upstream commit b773827e361952b3f53ac6fa4c4e39ccd632102e ]
The error message when I build vm tests on debian10 (GLIBC 2.28):
userfaultfd.c: In function `userfaultfd_pagemap_test':
userfaultfd.c:1393:37: error: MADV_PAGEOUT' undeclared (first use in this function); did you mean MADV_RANDOM'?
if (madvise(area_dst, test_pgsize, MADV_PAGEOUT))
^~~~~~~~~~~~ MADV_RANDOM
This patch includes these newer definitions from UAPI linux/mman.h, is useful to fix tests build on systems without these definitions in glibc sys/mman.h.
--- tools/testing/selftests/vm/userfaultfd.c | 1 + 1 file changed, 1 insertion(+)
tools/testing/selftests/vm/userfaultfd.c +1 -0
@@ -60,6 +60,7 @@#include <signal.h> #include <poll.h> #include <string.h> +#include <linux/mman.h> #include <sys/mman.h> #include <sys/syscall.h> #include <sys/ioctl.h>
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 11/16 fs: sysfs_emit: Remove PAGE_SIZE alignment check
In reply to Greg Kroah-HartmanFrom: Lucas Wei <[email protected]>
For kernel releases older than 4.20, using the SLUB alloctor will cause this alignment check to fail as that allocator did NOT align kmalloc allocations on a PAGE_SIZE boundry.
Remove the check for these older kernels as it is a false-positive and causes problems on many devices.
--- fs/sysfs/file.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
fs/sysfs/file.c +1 -2
@@ -565,8 +565,7 @@ int sysfs_emit(char *buf, const char *fmva_list args;int len; -if (WARN (!buf ||offset_in_page (buf), -"invalid sysfs_emit: buf:%p\n" , buf)) +if (WARN (!buf,"invalid sysfs_emit: buf:%p\n" , buf))return 0 ;va_start (args, fmt);
Greg Kroah-Hartman
maintainerPATCH 12/16 net/packet: fix slab-out-of-bounds access in packet_recvmsg()
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
[ Upstream commit c700525fcc06b05adfea78039de02628af79e07a ]
syzbot found that when an AF_PACKET socket is using PACKET_COPY_THRESH and mmap operations, tpacket_rcv() is queueing skbs with garbage in skb->cb[], triggering a too big copy [1]
Presumably, users of af_packet using mmap() already gets correct metadata from the mapped buffer, we can simply make sure to clear 12 bytes that might be copied to user space later.
BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:225 [inline] BUG: KASAN: stack-out-of-bounds in packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489 Write of size 165 at addr ffffc9000385fb78 by task syz-executor233/3631 CPU: 0 PID: 3631 Comm: syz-executor233 Not tainted 5.17.0-rc7-syzkaller-02396-g0b3660695e80 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xf/0x336 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189 memcpy+0x39/0x60 mm/kasan/shadow.c:66 memcpy include/linux/fortify-string.h:225 [inline] packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] sock_recvmsg net/socket.c:962 [inline] ____sys_recvmsg+0x2c4/0x600 net/socket.c:2632 ___sys_recvmsg+0x127/0x200 net/socket.c:2674 __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fdfd5954c29 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcf8e71e48 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdfd5954c29 RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000005 RBP: 0000000000000000 R08: 000000000000000d R09: 000000000000000d R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffcf8e71e60 R13: 00000000000f4240 R14: 000000000000c1ff R15: 00007ffcf8e71e54 </TASK>
addr ffffc9000385fb78 is located in stack of task syz-executor233/3631 at offset 32 in frame:
____sys_recvmsg+0x0/0x600 include/linux/uio.h:246
this frame has 1 object:
[32, 160) 'addr'
Memory state around the buggy address:
ffffc9000385fa80: 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00
ffffc9000385fb00: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
>ffffc9000385fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3
^
ffffc9000385fc00: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 f1
ffffc9000385fc80: f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2 00 00 00 00 00
==================================================================--- net/packet/af_packet.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
net/packet/af_packet.c +10 -1
@@ -2244,8 +2244,11 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev, copy_skb =skb_get (skb); skb_head = skb->data; } -if (copy_skb) +if (copy_skb) { +memset (&PACKET_SKB_CB (copy_skb)->sa.ll,0 , +sizeof (PACKET_SKB_CB (copy_skb)->sa.ll));skb_set_owner_r (copy_skb, sk); + } } snaplen = po->rx_ring.frame_size - macoff;if ((int )snaplen <0 ) {
@@ -3422,6 +3425,8 @@ static int packet_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,sock_recv_ts_and_drops (msg, sk, skb);if (msg->msg_name) { +const size_t max_len =min (sizeof (skb->cb), +sizeof (struct sockaddr_storage ));int copy_len;/* If the address length field is there to be filled
@@ -3444,6 +3449,10 @@ static int packet_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, msg->msg_namelen =sizeof (struct sockaddr_ll ); } } +if (WARN_ON_ONCE (copy_len > max_len)) { + copy_len = max_len; + msg->msg_namelen = copy_len; + }memcpy (msg->msg_name, &PACKET_SKB_CB (skb)->sa, copy_len); }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 13/16 atm: eni: Add check for dma_map_single
In reply to Greg Kroah-HartmanFrom: Jiasheng Jiang <[email protected]>
[ Upstream commit 0f74b29a4f53627376cf5a5fb7b0b3fa748a0b2b ]
As the potential failure of the dma_map_single(), it should be better to check it and return error if fails.
--- drivers/atm/eni.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/atm/eni.c +2 -0
@@ -1114,6 +1114,8 @@ DPRINTK("iovcnt = %d\n",skb_shinfo(skb)->nr_frags); } paddr =dma_map_single (&eni_dev->pci_dev->dev,skb->data,skb->len,DMA_TO_DEVICE ); +if (dma_mapping_error (&eni_dev->pci_dev->dev, paddr)) +return enq_next;ENI_PRV_PADDR (skb) = paddr;/* prepare DMA queue entries */ j =0 ;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 14/16 usb: gadget: rndis: prevent integer overflow in rndis_set_response()
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
commit 65f3324f4b6fed78b8761c3b74615ecf0ffa81fa upstream.
If "BufOffset" is very large the "BufOffset + 8" operation can have an integer overflow.
--- drivers/usb/gadget/function/rndis.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/gadget/function/rndis.c +1 -0
@@ -645,6 +645,7 @@ static int rndis_set_response(struct rnd BufLength =le32_to_cpu (buf->InformationBufferLength); BufOffset =le32_to_cpu (buf->InformationBufferOffset);if ((BufLength >RNDIS_MAX_TOTAL_SIZE ) || + (BufOffset >RNDIS_MAX_TOTAL_SIZE ) || (BufOffset +8 >=RNDIS_MAX_TOTAL_SIZE ))return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 15/16 usb: gadget: Fix use-after-free bug by not setting udc->dev.driver
In reply to Greg Kroah-HartmanFrom: Alan Stern <[email protected]>
commit 16b1941eac2bd499f065a6739a40ce0011a3d740 upstream.
The syzbot fuzzer found a use-after-free bug:
BUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:2320 Read of size 8 at addr ffff88802b934098 by task udevd/3689 CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 dev_uevent+0x712/0x780 drivers/base/core.c:2320 uevent_show+0x1b8/0x380 drivers/base/core.c:2391 dev_attr_show+0x4b/0x90 drivers/base/core.c:2094
Although the bug manifested in the driver core, the real cause was a race with the gadget core. dev_uevent() does:
if (dev->driver) add_uevent_var(env, "DRIVER=%s", dev->driver->name);
and between the test and the dereference of dev->driver, the gadget core sets dev->driver to NULL.
The race wouldn't occur if the gadget core registered its devices on a real bus, using the standard synchronization techniques of the driver core. However, it's not necessary to make such a large change in order to fix this bug; all we need to do is make sure that udc->dev.driver is always NULL.
In fact, there is no reason for udc->dev.driver ever to be set to anything, let alone to the value it currently gets: the address of the gadget's driver. After all, a gadget driver only knows how to manage a gadget, not how to manage a UDC.
This patch simply removes the statements in the gadget core that touch udc->dev.driver.
--- drivers/usb/gadget/udc/core.c | 3 --- 1 file changed, 3 deletions(-)
drivers/usb/gadget/udc/core.c +0 -3
@@ -1253,7 +1253,6 @@ static void usb_gadget_remove_driver(strusb_gadget_udc_stop (udc); udc->driver =NULL ; - udc->dev.driver =NULL ; udc->gadget->dev.driver =NULL ; }
@@ -1301,7 +1300,6 @@ static int udc_bind_to_driver(struct usb driver->function); udc->driver = driver; - udc->dev.driver = &driver->driver; udc->gadget->dev.driver = &driver->driver; ret = driver->bind (udc->gadget, driver);
@@ -1321,7 +1319,6 @@ err1:dev_err (&udc->dev,"failed to start %s: %d\n" , udc->driver->function, ret); udc->driver =NULL ; - udc->dev.driver =NULL ; udc->gadget->dev.driver =NULL ;return ret; }
Greg Kroah-Hartman
maintainerPATCH 16/16 Input: aiptek - properly check endpoint type
In reply to Greg Kroah-HartmanFrom: Pavel Skripkin <[email protected]>
commit 5600f6986628dde8881734090588474f54a540a8 upstream.
Syzbot reported warning in usb_submit_urb() which is caused by wrong endpoint type. There was a check for the number of endpoints, but not for the type of endpoint.
Fix it by replacing old desc.bNumEndpoints check with usb_find_common_endpoints() helper for finding endpoints
Fail log:
usb 5-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Workqueue: usb_hub_wq hub_event ... Call Trace: <TASK> aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830 input_open_device+0x1bb/0x320 drivers/input/input.c:629 kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593
--- drivers/input/tablet/aiptek.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
drivers/input/tablet/aiptek.c +4 -6
@@ -1821,15 +1821,13 @@ aiptek_probe(struct usb_interface *intf,input_set_abs_params (inputdev,ABS_TILT_Y ,AIPTEK_TILT_MIN ,AIPTEK_TILT_MAX ,0 ,0 );input_set_abs_params (inputdev,ABS_WHEEL ,AIPTEK_WHEEL_MIN ,AIPTEK_WHEEL_MAX -1 ,0 ,0 ); -/* Verify that a device really has an endpoint */ -if (intf->cur_altsetting->desc.bNumEndpoints <1 ) { + err =usb_find_common_endpoints (intf->cur_altsetting, +NULL ,NULL , &endpoint,NULL ); +if (err) {dev_err (&intf->dev, -"interface has %d endpoints, but must have minimum 1\n" , - intf->cur_altsetting->desc.bNumEndpoints); - err = -EINVAL ; +"interface has no int in endpoints, but must have minimum 1\n" ); goto fail3; } - endpoint = &intf->cur_altsetting->endpoint[0 ].desc;/* Go set up our URB, which is called when the tablet receives * input.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.308 release. There are 16 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 23 Mar 2022 13:32:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.308-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Signature · 1 line
Florian
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 4.9.308 release. There are 16 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.9.y
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.308 release. There are 16 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 23 Mar 2022 13:32:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.308-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v4.9:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
32 tests: 32 pass, 0 failLinux version: 4.9.308-rc1-g9edf1c247ba2
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.308 release. There are 16 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 23 Mar 2022 13:32:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.308-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.308 release. There are 16 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 23 Mar 2022 13:32:09 +0000. Anything received after that time might be too late.
Build results:
total: 163 pass: 163 fail: 0 Qemu test results: total: 397 pass: 397 fail: 0
Guenter
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.308 release. There are 16 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 23 Mar 2022 13:32:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.308-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 4.9.308-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-4.9.y
* git commit: 9edf1c247ba23173e6a105911ccdd3491f0f1a7e
* git describe: v4.9.307-17-g9edf1c247ba2
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.9.y/build/v4.9.307-17-g9edf1c247ba2
## Test Regressions (compared to v4.9.307-12-g907431a01b50) No test regressions found.
## Metric Regressions (compared to v4.9.307-12-g907431a01b50) No metric regressions found.
## Test Fixes (compared to v4.9.307-12-g907431a01b50) No test fixes found.
## Metric Fixes (compared to v4.9.307-12-g907431a01b50) No metric fixes found.
## Test result summary
total: 51902, pass: 42014, fail: 393, skip: 8470, xfail: 1025
## Build Summary
* arm: 254 total, 238 passed, 16 failed
* arm64: 32 total, 32 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 19 total, 18 passed, 1 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 22 total, 22 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 31 total, 31 passed, 0 failed
## Test suites summary
* kselftest-android
* kselftest-arm64
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org