4.14.273-rc1 review
Subsystems (3)
Greg Kroah-Hartman
maintainercover 4.14.273-rc1 review
This is the start of the stable review cycle for the 4.14.273 release. There are 22 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.14.273-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.14.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.14.273-rc1
Michael Petlan <[email protected]>
perf symbols: Fix symbol size calculation condition
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()
Nicolas Dichtel <[email protected]>
net: handle ARPHRD_PIMREG in dev_is_mac_header_xmit()
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()
Randy Dunlap <[email protected]>
efi: fix return value of __setup handlers
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
Jakob Unterwurzacher <[email protected]>
arm64: dts: rockchip: fix rk3399-puma eMMC HS400 signal integrity
Yan Yan <[email protected]>
xfrm: Fix xfrm migrate issues when address family changes
Xin Long <[email protected]>
sctp: fix the processing for INIT_ACK chunk
Xin Long <[email protected]>
sctp: fix the processing for INIT chunk
-------------
Diffstat:
Makefile | 4 +- arch/arm/boot/dts/rk3288.dtsi | 2 +- arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 6 ++ arch/mips/kernel/smp.c | 6 +- drivers/atm/eni.c | 2 + drivers/atm/firestream.c | 2 + drivers/firmware/efi/apple-properties.c | 2 +- drivers/firmware/efi/efi.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 +- include/linux/if_arp.h | 1 + lib/Kconfig | 1 - net/ipv4/tcp.c | 10 ++- net/packet/af_packet.c | 11 ++- net/sctp/sm_statefuns.c | 108 ++++++++++++++++---------- net/wireless/nl80211.c | 3 +- net/xfrm/xfrm_state.c | 8 +- tools/perf/util/symbol.c | 2 +- tools/testing/selftests/vm/userfaultfd.c | 1 + 23 files changed, 119 insertions(+), 77 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/22 sctp: fix the processing for INIT chunk
From: Xin Long <[email protected]>
commit eae5783908042a762c24e1bd11876edb91d314b1 upstream.
This patch fixes the problems below:
1. In non-shutdown_ack_sent states: in sctp_sf_do_5_1B_init() and sctp_sf_do_5_2_2_dupinit():
chunk length check should be done before any checks that may cause to send abort, as making packet for abort will access the init_tag from init_hdr in sctp_ootb_pkt_new().
2. In shutdown_ack_sent state: in sctp_sf_do_9_2_reshutack():
The same checks as does in sctp_sf_do_5_2_2_dupinit() is needed for sctp_sf_do_9_2_reshutack().
--- net/sctp/sm_statefuns.c | 71 +++++++++++++++++++++++++++++++----------------- 1 file changed, 46 insertions(+), 25 deletions(-)
net/sctp/sm_statefuns.c +46 -25
@@ -161,6 +161,12 @@ static enum sctp_disposition __sctp_sf_dvoid *arg, struct sctp_cmd_seq *commands); +static enum sctp_disposition +__sctp_sf_do_9_2_reshutack (struct net *net,const struct sctp_endpoint *ep, +const struct sctp_association *asoc, +const union sctp_subtype type,void *arg, +struct sctp_cmd_seq *commands); +/* Small helper function that checks if the chunk length * is of the appropriate length. The 'required_length' argument * is set to be the size of a specific chunk we are testing.
@@ -337,6 +343,14 @@ enum sctp_disposition sctp_sf_do_5_1B_inif (!chunk->singleton)return sctp_sf_pdiscard (net, ep, asoc, type, arg, commands); +/* Make sure that the INIT chunk has a valid length. +* Normally, this would cause an ABORT with a Protocol Violation +* error, but since we don't have an association, we'll +* just discard the packet. +*/ +if (!sctp_chunk_length_valid (chunk,sizeof (struct sctp_init_chunk ))) +return sctp_sf_pdiscard (net, ep, asoc, type, arg, commands); +/* If the packet is an OOTB packet which is temporarily on the * control endpoint, respond with an ABORT. */
@@ -351,14 +365,6 @@ enum sctp_disposition sctp_sf_do_5_1B_inif (chunk->sctp_hdr->vtag !=0 )return sctp_sf_tabort_8_4_8 (net, ep, asoc, type, arg, commands); -/* Make sure that the INIT chunk has a valid length. -* Normally, this would cause an ABORT with a Protocol Violation -* error, but since we don't have an association, we'll -* just discard the packet. -*/ -if (!sctp_chunk_length_valid (chunk,sizeof (struct sctp_init_chunk ))) -return sctp_sf_pdiscard (net, ep, asoc, type, arg, commands); -/* If the INIT is coming toward a closing socket, we'll send back * and ABORT. Essentially, this catches the race of INIT being * backloged to the socket at the same time as the user isses close().
@@ -1460,19 +1466,16 @@ static enum sctp_disposition sctp_sf_do_if (!chunk->singleton)return sctp_sf_pdiscard (net, ep, asoc, type, arg, commands); +/* Make sure that the INIT chunk has a valid length. */ +if (!sctp_chunk_length_valid (chunk,sizeof (struct sctp_init_chunk ))) +return sctp_sf_pdiscard (net, ep, asoc, type, arg, commands); +/* 3.1 A packet containing an INIT chunk MUST have a zero Verification * Tag. */ if (chunk->sctp_hdr->vtag !=0 )return sctp_sf_tabort_8_4_8 (net, ep, asoc, type, arg, commands); -/* Make sure that the INIT chunk has a valid length. -* In this case, we generate a protocol violation since we have -* an association established. -*/ -if (!sctp_chunk_length_valid (chunk,sizeof (struct sctp_init_chunk ))) -return sctp_sf_violation_chunklen (net, ep, asoc, type, arg, - commands);/* Grab the INIT header. */ chunk->subh.init_hdr = (struct sctp_inithdr *)chunk->skb->data;
@@ -1787,9 +1790,9 @@ static enum sctp_disposition sctp_sf_do_* its peer. */ if (sctp_state (asoc,SHUTDOWN_ACK_SENT )) { - disposition =sctp_sf_do_9_2_reshutack (net, ep, asoc, -SCTP_ST_CHUNK (chunk->chunk_hdr->type), - chunk, commands); + disposition =__sctp_sf_do_9_2_reshutack (net, ep, asoc, +SCTP_ST_CHUNK (chunk->chunk_hdr->type), + chunk, commands);if (SCTP_DISPOSITION_NOMEM == disposition) goto nomem;
@@ -2847,13 +2850,11 @@ enum sctp_disposition sctp_sf_do_9_2_shu* that belong to this association, it should discard the INIT chunk and * retransmit the SHUTDOWN ACK chunk. */ -enum sctp_disposition sctp_sf_do_9_2_reshutack ( -struct net *net, -const struct sctp_endpoint *ep, -const struct sctp_association *asoc, -const union sctp_subtype type, -void *arg, -struct sctp_cmd_seq *commands) +static enum sctp_disposition +__sctp_sf_do_9_2_reshutack (struct net *net,const struct sctp_endpoint *ep, +const struct sctp_association *asoc, +const union sctp_subtype type,void *arg, +struct sctp_cmd_seq *commands) {struct sctp_chunk *chunk = arg;struct sctp_chunk *reply;
@@ -2887,6 +2888,26 @@ nomem:return SCTP_DISPOSITION_NOMEM ; } +enum sctp_disposition +sctp_sf_do_9_2_reshutack (struct net *net,const struct sctp_endpoint *ep, +const struct sctp_association *asoc, +const union sctp_subtype type,void *arg, +struct sctp_cmd_seq *commands) +{ +struct sctp_chunk *chunk = arg; + +if (!chunk->singleton) +return sctp_sf_pdiscard (net, ep, asoc, type, arg, commands); + +if (!sctp_chunk_length_valid (chunk,sizeof (struct sctp_init_chunk ))) +return sctp_sf_pdiscard (net, ep, asoc, type, arg, commands); + +if (chunk->sctp_hdr->vtag !=0 ) +return sctp_sf_tabort_8_4_8 (net, ep, asoc, type, arg, commands); + +return __sctp_sf_do_9_2_reshutack (net, ep, asoc, type, arg, commands); +} +/* * sctp_sf_do_ecn_cwr *
Greg Kroah-Hartman
maintainerPATCH 2/22 sctp: fix the processing for INIT_ACK chunk
In reply to Greg Kroah-HartmanFrom: Xin Long <[email protected]>
commit 438b95a7c98f77d51cbf4db021f41b602d750a3f upstream.
Currently INIT_ACK chunk in non-cookie_echoed state is processed in sctp_sf_discard_chunk() to send an abort with the existent asoc's vtag if the chunk length is not valid. But the vtag in the chunk's sctphdr is not verified, which may be exploited by one to cook a malicious chunk to terminal a SCTP asoc.
sctp_sf_discard_chunk() also is called in many other places to send an abort, and most of those have this problem. This patch is to fix it by sending abort with the existent asoc's vtag only if the vtag from the chunk's sctphdr is verified in sctp_sf_discard_chunk().
Note on sctp_sf_do_9_1_abort() and sctp_sf_shutdown_pending_abort(), the chunk length has been verified before sctp_sf_discard_chunk(), so replace it with sctp_sf_discard(). On sctp_sf_do_asconf_ack() and sctp_sf_do_asconf(), move the sctp_chunk_length_valid check ahead of sctp_sf_discard_chunk(), then replace it with sctp_sf_discard().
--- net/sctp/sm_statefuns.c | 37 +++++++++++++++++++------------------ 1 file changed, 19 insertions(+), 18 deletions(-)
net/sctp/sm_statefuns.c +19 -18
@@ -2221,7 +2221,7 @@ enum sctp_disposition sctp_sf_shutdown_p*/ if (SCTP_ADDR_DEL ==sctp_bind_addr_state (&asoc->base.bind_addr, &chunk->dest)) -return sctp_sf_discard_chunk (net, ep, asoc, type, arg, commands); +return sctp_sf_pdiscard (net, ep, asoc, type, arg, commands);if (!sctp_err_chunk_valid (chunk))return sctp_sf_pdiscard (net, ep, asoc, type, arg, commands);
@@ -2267,7 +2267,7 @@ enum sctp_disposition sctp_sf_shutdown_s*/ if (SCTP_ADDR_DEL ==sctp_bind_addr_state (&asoc->base.bind_addr, &chunk->dest)) -return sctp_sf_discard_chunk (net, ep, asoc, type, arg, commands); +return sctp_sf_pdiscard (net, ep, asoc, type, arg, commands);if (!sctp_err_chunk_valid (chunk))return sctp_sf_pdiscard (net, ep, asoc, type, arg, commands);
@@ -2537,7 +2537,7 @@ enum sctp_disposition sctp_sf_do_9_1_abo*/ if (SCTP_ADDR_DEL ==sctp_bind_addr_state (&asoc->base.bind_addr, &chunk->dest)) -return sctp_sf_discard_chunk (net, ep, asoc, type, arg, commands); +return sctp_sf_pdiscard (net, ep, asoc, type, arg, commands);if (!sctp_err_chunk_valid (chunk))return sctp_sf_pdiscard (net, ep, asoc, type, arg, commands);
@@ -3702,6 +3702,11 @@ enum sctp_disposition sctp_sf_do_asconf(return sctp_sf_pdiscard (net, ep, asoc, type, arg, commands); } +/* Make sure that the ASCONF ADDIP chunk has a valid length. */ +if (!sctp_chunk_length_valid (chunk,sizeof (struct sctp_addip_chunk ))) +return sctp_sf_violation_chunklen (net, ep, asoc, type, arg, + commands); +/* ADD-IP: Section 4.1.1 * This chunk MUST be sent in an authenticated way by using * the mechanism defined in [I-D.ietf-tsvwg-sctp-auth]. If this chunk
@@ -3709,13 +3714,7 @@ enum sctp_disposition sctp_sf_do_asconf(* described in [I-D.ietf-tsvwg-sctp-auth]. */ if (!net->sctp.addip_noauth && !chunk->auth) -return sctp_sf_discard_chunk (net, ep, asoc, type, arg, - commands); - -/* Make sure that the ASCONF ADDIP chunk has a valid length. */ -if (!sctp_chunk_length_valid (chunk,sizeof (struct sctp_addip_chunk ))) -return sctp_sf_violation_chunklen (net, ep, asoc, type, arg, - commands); +return sctp_sf_pdiscard (net, ep, asoc, type, arg, commands); hdr = (struct sctp_addiphdr *)chunk->skb->data; serial =ntohl (hdr->serial);
@@ -3844,6 +3843,12 @@ enum sctp_disposition sctp_sf_do_asconf_return sctp_sf_pdiscard (net, ep, asoc, type, arg, commands); } +/* Make sure that the ADDIP chunk has a valid length. */ +if (!sctp_chunk_length_valid (asconf_ack, +sizeof (struct sctp_addip_chunk ))) +return sctp_sf_violation_chunklen (net, ep, asoc, type, arg, + commands); +/* ADD-IP, Section 4.1.2: * This chunk MUST be sent in an authenticated way by using * the mechanism defined in [I-D.ietf-tsvwg-sctp-auth]. If this chunk
@@ -3851,14 +3856,7 @@ enum sctp_disposition sctp_sf_do_asconf_* described in [I-D.ietf-tsvwg-sctp-auth]. */ if (!net->sctp.addip_noauth && !asconf_ack->auth) -return sctp_sf_discard_chunk (net, ep, asoc, type, arg, - commands); - -/* Make sure that the ADDIP chunk has a valid length. */ -if (!sctp_chunk_length_valid (asconf_ack, -sizeof (struct sctp_addip_chunk ))) -return sctp_sf_violation_chunklen (net, ep, asoc, type, arg, - commands); +return sctp_sf_pdiscard (net, ep, asoc, type, arg, commands); addip_hdr = (struct sctp_addiphdr *)asconf_ack->skb->data; rcvd_serial =ntohl (addip_hdr->serial);
@@ -4435,6 +4433,9 @@ enum sctp_disposition sctp_sf_discard_ch {struct sctp_chunk *chunk = arg; +if (asoc && !sctp_vtag_verify (chunk, asoc)) +return sctp_sf_pdiscard (net, ep, asoc, type, arg, commands); +/* Make sure that the chunk has a valid length. * Since we don't know the chunk type, we use a general * chunkhdr structure to make a comparison.
Greg Kroah-Hartman
maintainerPATCH 3/22 xfrm: Fix xfrm migrate issues when address family changes
In reply to Greg Kroah-HartmanFrom: 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
@@ -1421,9 +1421,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;
@@ -1501,6 +1498,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 4/22 arm64: dts: rockchip: fix rk3399-puma eMMC HS400 signal integrity
In reply to Greg Kroah-HartmanFrom: Jakob Unterwurzacher <[email protected]>
[ Upstream commit 62966cbdda8a92f82d966a45aa671e788b2006f7 ]
There are signal integrity issues running the eMMC at 200MHz on Puma RK3399-Q7.
Similar to the work-around found for RK3399 Gru boards, lowering the frequency to 100MHz made the eMMC much more stable, so let's lower the frequency to 100MHz.
It might be possible to run at 150MHz as on RK3399 Gru boards but only 100MHz was extensively tested.
--- arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 6 ++++++ 1 file changed, 6 insertions(+)
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi +6 -0
@@ -484,6 +484,12 @@ }; &sdhci { + /* + * Signal integrity isn't great at 200MHz but 100MHz has proven stable + * enough. + */ + max-frequency = <100000000>; + bus-width = <8>; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 5/22 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
@@ -943,7 +943,7 @@ status = "disabled"; }; - crypto: cypto-controller@ff8a0000 { + crypto: crypto@ff8a0000 { compatible = "rockchip,rk3288-crypto"; reg = <0x0 0xff8a0000 0x0 0x4000>; interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 6/22 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
@@ -372,6 +372,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);
@@ -383,9 +386,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 7/22 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 8/22 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
@@ -1602,15 +1602,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 9/22 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 10/22 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
@@ -14777,7 +14777,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 11/22 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
@@ -1657,11 +1657,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 12/22 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
@@ -167,9 +167,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 13/22 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 14/22 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 15/22 efi: fix return value of __setup handlers
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
[ Upstream commit 9feaf8b387ee0ece9c1d7add308776b502a35d0c ]
When "dump_apple_properties" is used on the kernel boot command line, it causes an Unknown parameter message and the string is added to init's argument strings:
Unknown kernel command line parameters "dump_apple_properties
BOOT_IMAGE=/boot/bzImage-517rc6 efivar_ssdt=newcpu_ssdt", will be passed to user space.
Run /sbin/init as init process
with arguments:
/sbin/init
dump_apple_properties
with environment:
HOME=/
TERM=linux
BOOT_IMAGE=/boot/bzImage-517rc6
efivar_ssdt=newcpu_ssdtSimilarly when "efivar_ssdt=somestring" is used, it is added to the Unknown parameter message and to init's environment strings, polluting them (see examples above).
Change the return value of the __setup functions to 1 to indicate that the __setup options have been handled.
--- drivers/firmware/efi/apple-properties.c | 2 +- drivers/firmware/efi/efi.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
drivers/firmware/efi/apple-properties.c +1 -1
@@ -30,7 +30,7 @@ static bool dump_properties __initdata;static int __init dump_properties_enable (char *arg) { dump_properties = true; -return 0 ; +return 1 ; }__setup ("dump_apple_properties" , dump_properties_enable);
drivers/firmware/efi/efi.c +1 -1
@@ -230,7 +230,7 @@ static int __init efivar_ssdt_setup(char *str)memcpy (efivar_ssdt, str,strlen (str)); else pr_warn("efivar_ssdt: name too long: %s\n", str); -return 0 ; +return 1 ; }__setup ("efivar_ssdt=" , efivar_ssdt_setup);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 16/22 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
@@ -2285,8 +2285,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 ) {
@@ -3442,6 +3445,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
@@ -3464,6 +3469,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 17/22 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 18/22 net: handle ARPHRD_PIMREG in dev_is_mac_header_xmit()
In reply to Greg Kroah-HartmanFrom: Nicolas Dichtel <[email protected]>
[ Upstream commit 4ee06de7729d795773145692e246a06448b1eb7a ]
This kind of interface doesn't have a mac header. This patch fixes bpf_redirect() to a PIM interface.
--- include/linux/if_arp.h | 1 + 1 file changed, 1 insertion(+)
include/linux/if_arp.h +1 -0
@@ -55,6 +55,7 @@ static inline bool dev_is_mac_header_xmit(const struct net_device *dev)case ARPHRD_VOID :case ARPHRD_NONE :case ARPHRD_RAWIP : +case ARPHRD_PIMREG :return false;default :return true;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 19/22 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
@@ -643,6 +643,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 20/22 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
@@ -1284,7 +1284,6 @@ static void usb_gadget_remove_driver(strusb_gadget_udc_stop (udc); udc->driver =NULL ; - udc->dev.driver =NULL ; udc->gadget->dev.driver =NULL ; }
@@ -1333,7 +1332,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;usb_gadget_udc_set_speed (udc, driver->max_speed);
@@ -1355,7 +1353,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 21/22 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.
Greg Kroah-Hartman
maintainerPATCH 22/22 perf symbols: Fix symbol size calculation condition
In reply to Greg Kroah-HartmanFrom: Michael Petlan <[email protected]>
commit 3cf6a32f3f2a45944dd5be5c6ac4deb46bcd3bee upstream.
Before this patch, the symbol end address fixup to be called, needed two conditions being met:
if (prev->end == prev->start && prev->end != curr->start)
Where
"prev->end == prev->start" means that prev is zero-long
(and thus needs a fixup)
and
"prev->end != curr->start" means that fixup hasn't been applied yet
However, this logic is incorrect in the following situation:
*curr = {rb_node = {__rb_parent_color = 278218928,
rb_right = 0x0, rb_left = 0x0},
start = 0xc000000000062354,
end = 0xc000000000062354, namelen = 40, type = 2 '\002', binding = 0 '\000', idle = 0 '\000', ignore = 0 '\000', inlined = 0 '\000', arch_sym = 0 '\000', annotate2 = false, name = 0x1159739e "kprobe_optinsn_page\t[__builtin__kprobes]"}
*prev = {rb_node = {__rb_parent_color = 278219041,
rb_right = 0x109548b0, rb_left = 0x109547c0}, start = 0xc000000000062354,
end = 0xc000000000062354, namelen = 12, type = 2 '\002', binding = 1 '\001', idle = 0 '\000', ignore = 0 '\000', inlined = 0 '\000', arch_sym = 0 '\000', annotate2 = false, name = 0x1095486e "optinsn_slot"}
In this case, prev->start == prev->end == curr->start == curr->end, thus the condition above thinks that "we need a fixup due to zero length of prev symbol, but it has been probably done, since the prev->end == curr->start", which is wrong.
After the patch, the execution path proceeds to arch__symbols__fixup_end function which fixes up the size of prev symbol by adding page_size to its end offset.
--- tools/perf/util/symbol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/perf/util/symbol.c +1 -1
@@ -224,7 +224,7 @@ void symbols__fixup_end(struct rb_root * prev = curr; curr = rb_entry(nd, struct symbol, rb_node); -if (prev->end == prev->start && prev->end != curr->start) +if (prev->end == prev->start || prev->end != curr->start)arch__symbols__fixup_end (prev, curr); }
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.273 release. There are 22 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.14.273-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v4.14:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
32 tests: 32 pass, 0 failLinux version: 4.14.273-rc1-g7d28b4c6f458
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Jon
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.273 release. There are 22 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: 168 pass: 168 fail: 0 Qemu test results: total: 424 pass: 424 fail: 0
Guenter
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.273 release. There are 22 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.14.273-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.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.14.273-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-4.14.y
* git commit: 7d28b4c6f4588cfdd8cd0d45f9183570fae70ffb
* git describe: v4.14.272-23-g7d28b4c6f458
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14.272-23-g7d28b4c6f458
## Test Regressions (compared to v4.14.272-15-gd7a314aa75d7) No test regressions found.
## Metric Regressions (compared to v4.14.272-15-gd7a314aa75d7) No metric regressions found.
## Test Fixes (compared to v4.14.272-15-gd7a314aa75d7) No test fixes found.
## Metric Fixes (compared to v4.14.272-15-gd7a314aa75d7) No metric fixes found.
## Test result summary
total: 80301, pass: 64836, fail: 778, skip: 12411, xfail: 2276
## Build Summary
* arm: 280 total, 270 passed, 10 failed
* arm64: 35 total, 35 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 19 total, 19 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 22 total, 22 passed, 0 failed
* powerpc: 24 total, 0 passed, 24 failed
* sparc: 12 total, 12 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 34 total, 34 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* 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-net
* kselftest-netfilter
* kselftest-nsfs
* 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-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kvm-unit-tests
* 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
* rcutorture
* ssuite
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org