- 08 Nov, 2017 40 commits
-
-
Lukasz Majewski authored
[ Upstream commit ac6e058b ] The DP83867 when not properly bootstrapped - especially with LED_0 pin - can enter N/A MODE4 for "port mirroring" feature. To provide normal operation of the PHY, one needs not only to explicitly disable the port mirroring feature, but as well stop some IC internal testing (which disables RGMII communication). To do that the STRAP_STS1 (0x006E) register must be read and RESERVED bit 11 examined. When it is set, the another RESERVED bit (11) at PHYCR (0x0010) register must be clear to disable testing mode and enable RGMII communication. Thorough explanation of the problem can be found at following e2e thread: "DP83867IR: Problem with RESERVED bits in PHY Control Register (PHYCR) - Linux driver" https://e2e.ti.com/support/interface/ethernet/f/903/p/571313/2096954#2096954Signed-off-by:
Lukasz Majewski <lukma@denx.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ding Tianhong authored
[ Upstream commit 729e5522 ] This erratum describes a bug in logic outside the core, so MIDR can't be used to identify its presence, and reading an SoC-specific revision register from common arch timer code would be awkward. So, describe it in the device tree. Signed-off-by:
Ding Tianhong <dingtianhong@huawei.com> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
-
Fabio Estevam authored
[ Upstream commit ef15d361 ] clk_prepare_enable() may fail, so we should better check its return value. Also place the of_node_put() function right after clk_prepare_enable(), in order to avoid calling of_node_put() twice in case clk_prepare_enable() fails. Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Emmanuel Grumbach authored
[ Upstream commit d45cb20e ] When we send a deauth to a station we don't know about, we need to use the PROBE_RESP queue. This can happen when we send a deauth to a station that is not associated to us. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Taeung Song authored
[ Upstream commit 75fc5ae5 ] Signed-off-by:
Taeung Song <treeze.taeung@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/r/1485952447-7013-2-git-send-email-treeze.taeung@gmail.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Rex Zhu authored
[ Upstream commit 28ed5504 ] Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Chris Brandt authored
[ Upstream commit 71ccea09 ] This fixes the condition where the controller has not fully completed its final transfer and leaves the bus and controller in a undesirable state. At the end of the last transmitted byte, the existing driver would just signal for a STOP condition to be transmitted then immediately signal completion. However, the full STOP procedure might not have fully taken place by the time the runtime PM shuts off the peripheral clock, leaving the bus in a suspended state. Alternatively, the STOP condition on the bus may have completed, but when the next transaction is requested by the upper layer, not all the necessary register cleanup was finished from the last transfer which made the driver return BUS BUSY when it really wasn't. This patch now makes all transmit and receive transactions wait for the STOP condition to fully complete before signaling a completed transaction. With this new method, runtime PM no longer seems to be an issue. Fixes: 310c18a4 ("i2c: riic: add driver") Signed-off-by:
Chris Brandt <chris.brandt@renesas.com> Reviewed-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Netanel Belgazal authored
[ Upstream commit 7102a18a ] The timeouts were too agressive and sometimes cause false alarms. Signed-off-by:
Netanel Belgazal <netanel@annapurnalabs.com> Signed-off-by:
-
Jan Kara authored
[ Upstream commit 5469d7c3 ] Avoid using stripe_width for sbi->s_stripe value if it is not actually set. It prevents using the stride for sbi->s_stripe. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Jan Kara authored
[ Upstream commit d9b22cf9 ] When a filesystem is created using: mkfs.ext4 -b 4096 -E stride=512 <dev> and we try to allocate 64MB extent, we will end up directly in ext4_mb_complex_scan_group(). This is because the request is detected as power-of-two allocation (so we start in ext4_mb_regular_allocator() with ac_criteria == 0) however the check before ext4_mb_simple_scan_group() refuses the direct buddy scan because the allocation request is too large. Since cr == 0, the check whether we should use ext4_mb_scan_aligned() fails as well and we fall back to ext4_mb_complex_scan_group(). Fix the problem by checking for upper limit on power-of-two requests directly when detecting them. Reported-by:
Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by:
-
Russell King authored
[ Upstream commit 9303ab2b ] drivers/net/ethernet/marvell/mvneta.c:2694:26: error: storage size of 'status' isn't known drivers/net/ethernet/marvell/mvneta.c:2695:26: error: storage size of 'changed' isn't known drivers/net/ethernet/marvell/mvneta.c:2695:9: error: variable 'changed' has initializer but incomplete type drivers/net/ethernet/marvell/mvneta.c:2709:2: error: implicit declaration of function 'fixed_phy_update_state' [-Werror=implicit-function-declaration] Add linux/phy_fixed.h to mvneta.c Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Acked-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 3adfb572 ] If alloc_msi_entry() fails, we free resources and set ret = -ENOMEM. However, msix_setup_entries() returns 0 unconditionally. Return the error code instead. Fixes: e75eafb9 ("genirq/msi: Switch to new irq spreading infrastructure") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Larry Finger authored
[ Upstream commit 221c46d2 ] The headers describing a number of network packets do not have the correct endian settings for several types of data. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Deepak Khungar authored
[ Upstream commit 32b40798 ] Signed-off-by:
Deepak Khungar <deepak.khungar@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 1af468eb ] The R in PEK_DBR stands for rising, so it should be mapped to AXP288_IRQ_POKP where the last P stands for positive edge. Likewise PEK_DBF should be mapped to the falling edge, aka the _N_egative edge, so it should be mapped to AXP288_IRQ_POKN. This fixes the inverted powerbutton status reporting by the axp20x-pek driver. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Linus Walleij authored
[ Upstream commit 7e9c40c6 ] In the current boot, clients making use of the AB8500 sysctrl may be probed before the ab8500-sysctrl driver. This gives them -EINVAL, but should rather give -EPROBE_DEFER. Before this, the abx500 clock driver didn't probe properly, and as a result the codec driver in turn using the clocks did not probe properly. After this patch, everything probes properly. Also add OF compatible-string probing. This driver is all device tree, so let's just make a drive-by-fix of that as well. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit e1c6ec26 ] I got this new build error on today's linux-next drivers/mmc/host/s3cmci.h:69:24: error: field 'pio_tasklet' has incomplete type struct tasklet_struct pio_tasklet; drivers/mmc/host/s3cmci.c: In function 's3cmci_enable_irq': drivers/mmc/host/s3cmci.c:390:4: error: implicit declaration of function 'enable_irq';did you mean 'enable_imask'? [-Werror=implicit-function-declaration] While I haven't found out why this happened now and not earlier, the solution is obvious, we should include the header that defines the structure. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Shivasharan S authored
scsi: megaraid_sas: Do not set fp_possible if TM capable for non-RW syspdIO, change fp_possible to bool [ Upstream commit 1d6dbd17 ] FIX - firmware wants non-RW SYS PD IOs to avoid FastPath for better tracking and other functionalities if the device is task management capable. Signed-off-by:
Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by:
Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Grygorii Strashko authored
[ Upstream commit 09bb6e93 ] There are two reasons for reporting wakeup event when dedicated wakeup IRQ is triggered: - wakeup events accounting, so proper statistical data will be displayed in sysfs and debugfs; - there are small window when System is entering suspend during which dedicated wakeup IRQ can be lost: dpm_suspend_noirq() |- device_wakeup_arm_wake_irqs() |- dev_pm_arm_wake_irq(X) |- IRQ is enabled and marked as wakeup source [1]... |- suspend_device_irqs() |- suspend_device_irq(X) |- irqd_set(X, IRQD_WAKEUP_ARMED); |- wakup IRQ armed The wakeup IRQ can be lost if it's triggered at point [1] and not armed yet. Hence, fix above cases by adding simple pm_wakeup_event() call in handle_threaded_wake_irq(). Fixes: 4990d4fe (PM / Wakeirq: Add automated device wake IRQ handling) Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Tested-by:
Keerthy <j-keerthy@ti.com> [ tony@atomide.com: added missing return to avoid warnings ] Tested-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Majd Dibbiny authored
[ Upstream commit ed88451e ] For Routable RoCE QPs, the DSCP should be set in the QP's address path. The DSCP's value is derived from the traffic class. Fixes: 2811ba51 ("IB/mlx5: Add RoCE fields to Address Vector") Cc: Achiad Shochat <achiad@mellanox.com> Signed-off-by:
Majd Dibbiny <majd@mellanox.com> Reviewed-by:
Moni Shoua <monis@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Reviewed-by:
Yuval Shaia <yuval.shaia@oracle.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Bogdan Purcareata authored
[ Upstream commit 07e9ef14 ] Compiling the fsl-mc bus driver will yield a couple of static analysis errors: warning: symbol 'fsl_mc_msi_domain_alloc_irqs' was not declared warning: symbol 'fsl_mc_msi_domain_free_irqs' was not declared. warning: symbol 'its_fsl_mc_msi_init' was not declared. warning: symbol 'its_fsl_mc_msi_cleanup' was not declared. Since these are properly declared, but the header is not included, add it in the source files. This way the symbol is properly exported. Signed-off-by:
Bogdan Purcareata <bogdan.purcareata@gmail.com> Signed-off-by:
-
Gary R Hook authored
[ Upstream commit f7cc02b3 ] Ensure that the size field is correctly populated for all AES modes. Signed-off-by:
Gary R Hook <gary.hook@amd.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Rafael J. Wysocki authored
[ Upstream commit f4510146 ] If new_policy is set in cpufreq_online(), the policy object has just been created and its real_cpus mask has been zeroed on allocation, and the driver's ->init() callback should not touch it. It doesn't need to be cleared again, so don't do that. Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Linus Torvalds authored
commit a0cb2b5c upstream. Commit 6575257c ("tracing/samples: Fix creation and deletion of simple_thread_fn creation") introduced a new warning due to using a boolean as a counter. Just make it "int". Fixes: 6575257c ("tracing/samples: Fix creation and deletion of simple_thread_fn creation") Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Steven Rostedt (VMware) authored
commit 6575257c upstream. Commit 7496946a ("tracing: Add samples of DECLARE_EVENT_CLASS() and DEFINE_EVENT()") added template examples for all the events. It created a DEFINE_EVENT_FN() example which reused the foo_bar_reg and foo_bar_unreg functions. Enabling both the TRACE_EVENT_FN() and DEFINE_EVENT_FN() example trace events caused the foo_bar_reg to be called twice, creating the test thread twice. The foo_bar_unreg would remove it only once, even if it was called multiple times, leaving a thread existing when the module is unloaded, causing an oops. Add a ref count and allow foo_bar_reg() and foo_bar_unreg() be called by multiple trace events. Fixes: 7496946a ("tracing: Add samples of DECLARE_EVENT_CLASS() and DEFINE_EVENT()") Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Dan Carpenter authored
commit 65e93108 upstream. We recently added an integer overflow check but it needs an additional tweak to work properly on 32 bit systems. The problem is that we're doing the right hand side of the assignment as type unsigned long so the max it will have an integer overflow instead of being larger than SIZE_MAX. That means the "sz > SIZE_MAX" condition is never true even on 32 bit systems. We need to first cast it to u64 and then do the math. Fixes: 4a630fad ("drm/msm: Fix potential buffer overflow issue") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
Rob Clark <robdclark@gmail.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Kasin Li authored
commit 4a630fad upstream. In function submit_create, if nr_cmds or nr_bos is assigned with negative value, the allocated buffer may be small than intended. Using this buffer will lead to buffer overflow issue. Signed-off-by:
Kasin Li <donglil@codeaurora.org> Signed-off-by:
-
Jani Nikula authored
commit 7c838e2a upstream. Per my reading of the eDP spec, DP_DPCD_DISPLAY_CONTROL_CAPABLE bit in DP_EDP_CONFIGURATION_CAP should be set if the eDP display control registers starting at offset DP_EDP_DPCD_REV are "enabled". Currently we check the bit before reading the registers, and DP_EDP_DPCD_REV is the only way to detect eDP revision. Turns out there are (likely buggy) displays that require eDP 1.4+ features, such as supported link rates and link rate select, but do not have the bit set. Read the display control registers unconditionally. They are supposed to read zero anyway if they are not supported, so there should be no harm in this. This fixes the referenced bug by enabling the eDP version check, and thus reading of the supported link rates. The panel in question has 0 in DP_MAX_LINK_RATE which is only supported in eDP 1.4+. Without the supported link rates method we default to RBR which is insufficient for the panel native mode. As a curiosity, the panel also has a bogus value of 0x12 in DP_EDP_DPCD_REV, but that passes our check for >= DP_EDP_14 (which is 0x03). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103400Reported-and-tested-by:
Nicolas P. <issun.artiste@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171026142932.17737-1-jani.nikula@intel.com (cherry picked from commit 0501a3b0) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Ashish Samant authored
commit 105ddc93 upstream. The first cluster group descriptor is not stored at the start of the group but at an offset from the start. We need to take this into account while doing fstrim on the first cluster group. Otherwise we will wrongly start fstrim a few blocks after the desired start block and the range can cross over into the next cluster group and zero out the group descriptor there. This can cause filesytem corruption that cannot be fixed by fsck. Link: http://lkml.kernel.org/r/1507835579-7308-1-git-send-email-ashish.samant@oracle.comSigned-off-by:
Ashish Samant <ashish.samant@oracle.com> Reviewed-by:
Junxiao Bi <junxiao.bi@oracle.com> Reviewed-by:
Joseph Qi <jiangqi903@gmail.com> Cc: Mark Fasheh <mfasheh@versity.com> Cc: Joel Becker <jlbec@evilplan.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Leo Liu authored
commit cb4b02d7 upstream. Fixes init failures on polaris cards with harvested UVD. Signed-off-by:
Leo Liu <leo.liu@amd.com> Reviewed-by:
-
Arnd Bergmann authored
commit 1cce91df upstream. The asm-generic/unaligned.h header provides two different implementations for accessing unaligned variables: the access_ok.h version used when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set pretends that all pointers are in fact aligned, while the le_struct.h version convinces gcc that the alignment of a pointer is '1', to make it issue the correct load/store instructions depending on the architecture flags. On ARMv5 and older, we always use the second version, to let the compiler use byte accesses. On ARMv6 and newer, we currently use the access_ok.h version, so the compiler can use any instruction including stm/ldm and ldrd/strd that will cause an alignment trap. This trap can significantly impact performance when we have to do a lot of fixups and, worse, has led to crashes in the LZ4 decompressor code that does not have a trap handler. This adds an ARM specific version of asm/unaligned.h that uses the le_struct.h/be_struct.h implementation unconditionally. This should lead to essentially the same code on ARMv6+ as before, with the exception of using regular load/store instructions instead of the trapping instructions multi-register variants. The crash in the LZ4 decompressor code was probably introduced by the patch replacing the LZ4 implementation, commit 4e1a33b1 ("lib: update LZ4 compressor module"), so linux-4.11 and higher would be affected most. However, we probably want to have this backported to all older stable kernels as well, to help with the performance issues. There are two follow-ups that I think we should also work on, but not backport to stable kernels, first to change the asm-generic version of the header to remove the ARM special case, and second to review all other uses of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to see if they might be affected by the same problem on ARM. Signed-off-by:
-
Julien Thierry authored
commit f9b269f3 upstream. When HYP code runs into branch profiling code, it attempts to jump to unmapped memory, causing a HYP Panic. Disable the branch profiling for code designed to run at HYP mode. Signed-off-by:
Julien Thierry <julien.thierry@arm.com> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Cc: Christoffer Dall <christoffer.dall@linaro.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Russell King <linux@armlinux.org.uk> Signed-off-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
-
Dongjiu Geng authored
commit fd6c8c20 upstream. When a exception is trapped to EL2, hardware uses ELR_ELx to hold the current fault instruction address. If KVM wants to inject a abort to 32 bit guest, it needs to set the LR register for the guest to emulate this abort happened in the guest. Because ARM32 architecture is pipelined execution, so the LR value has an offset to the fault instruction address. The offsets applied to Link value for exceptions as shown below, which should be added for the ARM32 link register(LR). Table taken from ARMv8 ARM DDI0487B-B, table G1-10: Exception Offset, for PE state of: A32 T32 Undefined Instruction +4 +2 Prefetch Abort +4 +4 Data Abort +8 +8 IRQ or FIQ +4 +4 [ Removed unused variables in inject_abt to avoid compile warnings. -- Christoffer ] Signed-off-by:
Dongjiu Geng <gengdongjiu@huawei.com> Tested-by:
Haibin Zhang <zhanghaibin7@huawei.com> Reviewed-by:
Christoffer Dall <cdall@linaro.org> Signed-off-by:
-
Mark Rutland authored
commit 7a7003b1 upstream. It's possible for a user to deliberately trigger __dump_instr with a chosen kernel address. Let's avoid problems resulting from this by using get_user() rather than __get_user(), ensuring that we don't erroneously access kernel memory. Where we use __dump_instr() on kernel text, we already switch to KERNEL_DS, so this shouldn't adversely affect those cases. Fixes: 60ffc30d ("arm64: Exception handling") Acked-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Ricard Wanderlof authored
commit 1e6f4fc0 upstream. The ADC in the ADAU1361 (and possibly other Analog Devices codecs) exhibits a cyclic variation in the noise floor (in our test setup between -87 and -93 dB), a new value being attained within this range whenever a new capture stream is started. The cycle repeats after about 10 or 11 restarts. The workaround recommended by the manufacturer is to toggle the ADOSR bit in the Converter Control 0 register each time a new capture stream is started. I have verified that the patch fixes this problem on the ADAU1361, and according to the manufacturer toggling the bit in question in this manner will at least have no detrimental effect on other chips served by this driver. Signed-off-by:
Ricard Wanderlof <ricardw@axis.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Eric Biggers authored
commit 2eb9eabf upstream. syzkaller with KASAN reported an out-of-bounds read in asn1_ber_decoder(). It can be reproduced by the following command, assuming CONFIG_X509_CERTIFICATE_PARSER=y and CONFIG_KASAN=y: keyctl add asymmetric desc $'\x30\x30' @s The bug is that the length of an ASN.1 data value isn't validated in the case where it is encoded using the short form, causing the decoder to read past the end of the input buffer. Fix it by validating the length. The bug report was: BUG: KASAN: slab-out-of-bounds in asn1_ber_decoder+0x10cb/0x1730 lib/asn1_decoder.c:233 Read of size 1 at addr ffff88003cccfa02 by task syz-executor0/6818 CPU: 1 PID: 6818 Comm: syz-executor0 Not tainted 4.14.0-rc7-00008-g5f479447 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0xb3/0x10b lib/dump_stack.c:52 print_address_description+0x79/0x2a0 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 [inline] kasan_report+0x236/0x340 mm/kasan/report.c:409 __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:427 asn1_ber_decoder+0x10cb/0x1730 lib/asn1_decoder.c:233 x509_cert_parse+0x1db/0x650 crypto/asymmetric_keys/x509_cert_parser.c:89 x509_key_preparse+0x64/0x7a0 crypto/asymmetric_keys/x509_public_key.c:174 asymmetric_key_preparse+0xcb/0x1a0 crypto/asymmetric_keys/asymmetric_type.c:388 key_create_or_update+0x347/0xb20 security/keys/key.c:855 SYSC_add_key security/keys/keyctl.c:122 [inline] SyS_add_key+0x1cd/0x340 security/keys/keyctl.c:62 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x447c89 RSP: 002b:00007fca7a5d3bd8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f8 RAX: ffffffffffffffda RBX: 00007fca7a5d46cc RCX: 0000000000447c89 RDX: 0000000020006f4a RSI: 0000000020006000 RDI: 0000000020001ff5 RBP: 0000000000000046 R08: fffffffffffffffd R09: 0000000000000000 R10: 0000000000000002 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fca7a5d49c0 R15: 00007fca7a5d4700 Fixes: 42d5ec27 ("X.509: Add an ASN.1 decoder") Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
James Morris <james.l.morris@oracle.com> Signed-off-by:
-
Eric Biggers authored
commit 3239b6f2 upstream. Commit e645016a ("KEYS: fix writing past end of user-supplied buffer in keyring_read()") made keyring_read() stop corrupting userspace memory when the user-supplied buffer is too small. However it also made the return value in that case be the short buffer size rather than the size required, yet keyctl_read() is actually documented to return the size required. Therefore, switch it over to the documented behavior. Note that for now we continue to have it fill the short buffer, since it did that before (pre-v3.13) and dump_key_tree_aux() in keyutils arguably relies on it. Fixes: e645016a ("KEYS: fix writing past end of user-supplied buffer in keyring_read()") Reported-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Ronnie Sahlberg authored
commit f74bc7c6 upstream. And fix tcon leak in error path. Signed-off-by:
Ronnie Sahlberg <lsahlber@redhat.com> Signed-off-by:
Steve French <smfrench@gmail.com> Reviewed-by:
David Disseldorp <ddiss@samba.org> Signed-off-by:
-
Takashi Iwai authored
commit 1f20f9ff upstream. syzkaller reported the lockdep splat due to the possible deadlock of grp->list_mutex of each sequencer client object. Actually this is rather a false-positive report due to the missing nested lock annotations. The sequencer client may deliver the event directly to another client which takes another own lock. For addressing this issue, this patch replaces the simple down_read() with down_read_nested(). As a lock subclass, the already existing "hop" can be re-used, which indicates the depth of the call. Reference: http://lkml.kernel.org/r/089e082686ac9b482e055c832617@google.comReported-by:
syzbot <bot+7feb8de6b4d6bf810cf098bef942cc387e79d0ad@syzkaller.appspotmail.com> Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit 79fb0518 upstream. The races among ioctl and other operations were protected by the commit af368027 ("ALSA: timer: Fix race among timer ioctls") and later fixes, but one code path was forgotten in the scenario: the 32bit compat ioctl. As syzkaller recently spotted, a very similar use-after-free may happen with the combination of compat ioctls. The fix is simply to apply the same ioctl_lock to the compat_ioctl callback, too. Fixes: af368027 ("ALSA: timer: Fix race among timer ioctls") Reference: http://lkml.kernel.org/r/089e082686ac9b482e055c832617@google.comReported-by:
syzbot <bot+e5f3c9783e7048a74233054febbe9f1bdf54b6da@syzkaller.appspotmail.com> Signed-off-by:
-
