- Jan 20, 2022
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220118160450.062004175@linuxfoundation.org Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Hulk Robot <hulkrobot@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Nick Desaulniers authored
commit 28187dc8 upstream. LLD does not yet support any big endian architectures. Make this config non-selectable when using LLD until LLD is fixed. Link: https://github.com/ClangBuiltLinux/linux/issues/965 Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Tested-by:
Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Cc: Anders Roxell <anders.roxell@linaro.org> Signed-off-by:
-
Arnd Bergmann authored
commit 603362b4 upstream. drivers/mtd/maps/ixp4xx.c requires MTD_CFI_BE_BYTE_SWAP to be set in order to compile. drivers/mtd/maps/ixp4xx.c:57:4: error: #error CONFIG_MTD_CFI_BE_BYTE_SWAP required This patch avoids the #error output by enforcing the policy in Kconfig. Not sure if this is the right approach, but it helps doing randconfig builds. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210927141045.1597593-1-arnd@kernel.org Cc: Anders Roxell <anders.roxell@linaro.org> Signed-off-by:
-
Christian Lachner authored
commit c1933008 upstream. This patch addresses an issue where after rebooting from Windows into Linux there would be no audio output. It turns out that the Realtek Audio driver on Windows changes some coeffs which are not being reset/reinitialized when rebooting the machine. As a result, there is no audio output until these coeffs are being reset to their initial state. This patch takes care of that by setting known-good (initial) values to the coeffs. We initially relied upon alc1220_fixup_clevo_p950() to fix some pins in the connection list. However, it also sets coef 0x7 which does not need to be touched. Furthermore, to prevent mixing device-specific quirks I introduced a new alc1220_fixup_gb_x570() which is heavily based on alc1220_fixup_clevo_p950() but does not set coeff 0x7 and fixes the coeffs that are actually needed instead. This new alc1220_fixup_gb_x570() is believed to also work for other boards, like the Gigabyte X570 Aorus Extreme and the newer Gigabyte Aorus X570S Master. However, as there is no way for me to test these I initially only enable this new behaviour for the mainboard I have which is the Gigabyte X570(non-S) Aorus Master. I tested this patch on the 5.15 branch as well as on master and it is working well for me. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205275 Signed-off-by:
Christian Lachner <gladiac@gmail.com> Fixes: 0d45e86d ("ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Master") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220103140517.30273-2-gladiac@gmail.com Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Wei Wang authored
commit 9fb12fe5 upstream. The fixed counter 3 is used for the Topdown metrics, which hasn't been enabled for KVM guests. Userspace accessing to it will fail as it's not included in get_fixed_pmc(). This breaks KVM selftests on ICX+ machines, which have this counter. To reproduce it on ICX+ machines, ./state_test reports: ==== Test Assertion Failure ==== lib/x86_64/processor.c:1078: r == nmsrs pid=4564 tid=4564 - Argument list too long 1 0x000000000040b1b9: vcpu_save_state at processor.c:1077 2 0x0000000000402478: main at state_test.c:209 (discriminator 6) 3 0x00007fbe21ed5f92: ?? ??:0 4 0x000000000040264d: _start at ??:? Unexpected result from KVM_GET_MSRS, r: 17 (failed MSR was 0x30c) With this patch, it works well. Signed-off-by:
Wei Wang <wei.w.wang@intel.com> Message-Id: <20211217124934.32893-1-wei.w.wang@intel.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Fixes: e2ada66e ("kvm: x86: Add Intel PMU MSRs to msrs_to_save[]") Signed-off-by:
-
Johan Hovold authored
commit 47a1db8e upstream. An initialised kobject must be freed using kobject_put() to avoid leaking associated resources (e.g. the object name). Commit fe3c6068 ("firmware: Fix a reference count leak.") "fixed" the leak in the first error path of the file registration helper but left the second one unchanged. This "fix" would however result in a NULL pointer dereference due to the release function also removing the never added entry from the fw_cfg_entry_cache list. This has now been addressed. Fix the remaining kobject leak by restoring the common error path and adding the missing kobject_put(). Fixes: 75f3e8e4 ("firmware: introduce sysfs driver for QEMU's fw_cfg device") Cc: stable@vger.kernel.org # 4.6 Cc: Gabriel Somlo <somlo@cmu.edu> Signed-off-by:
Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20211201132528.30025-3-johan@kernel.org Signed-off-by:
-
Johan Hovold authored
commit d3e30559 upstream. Commit fe3c6068 ("firmware: Fix a reference count leak.") "fixed" a kobject leak in the file registration helper by properly calling kobject_put() for the entry in case registration of the object fails (e.g. due to a name collision). This would however result in a NULL pointer dereference when the release function tries to remove the never added entry from the fw_cfg_entry_cache list. Fix this by moving the list-removal out of the release function. Note that the offending commit was one of the benign looking umn.edu fixes which was reviewed but not reverted. [1][2] [1] https://lore.kernel.org/r/202105051005.49BFABCE@keescook [2] https://lore.kernel.org/all/YIg7ZOZvS3a8LjSv@kroah.com Fixes: fe3c6068 ("firmware: Fix a reference count leak.") Cc: stable@vger.kernel.org # 5.8 Cc: Qiushi Wu <wu000273@umn.edu> Cc: Kees Cook <keescook@chromium.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Johan Hovold authored
commit 1b656e9a upstream. Make sure to always NUL-terminate file names retrieved from the firmware to avoid accessing data beyond the entry slab buffer and exposing it through sysfs in case the firmware data is corrupt. Fixes: 75f3e8e4 ("firmware: introduce sysfs driver for QEMU's fw_cfg device") Cc: stable@vger.kernel.org # 4.6 Cc: Gabriel Somlo <somlo@cmu.edu> Signed-off-by:
-
Larry Finger authored
commit 8b144ded upstream. Syzbot reports the following WARNING: [200~raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 1 PID: 1206 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 Hardware initialization for the rtl8188cu can run for as long as 350 ms, and the routine may be called with interrupts disabled. To avoid locking the machine for this long, the current routine saves the interrupt flags and enables local interrupts. The problem is that it restores the flags at the end without disabling local interrupts first. This patch fixes commit a53268be ("rtlwifi: rtl8192cu: Fix too long disable of IRQs"). Reported-by:
<syzbot+cce1ee31614c171f5595@syzkaller.appspotmail.com> Cc: stable@vger.kernel.org Fixes: a53268be ("rtlwifi: rtl8192cu: Fix too long disable of IRQs") Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211215171105.20623-1-Larry.Finger@lwfinger.net Signed-off-by:
-
Johan Hovold authored
commit 8aa637bf upstream. Add the missing bulk-endpoint max-packet sanity check to uvc_video_start_transfer() to avoid division by zero in uvc_alloc_urb_buffers() in case a malicious device has broken descriptors (or when doing descriptor fuzz testing). Note that USB core will reject URBs submitted for endpoints with zero wMaxPacketSize but that drivers doing packet-size calculations still need to handle this (cf. commit 2548288b ("USB: Fix: Don't skip endpoint descriptors with maxpacket=0")). Fixes: c0efd232 ("V4L/DVB (8145a): USB Video Class driver") Cc: stable@vger.kernel.org # 2.6.26 Signed-off-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
-
Eric Farman authored
commit 812de046 upstream. With KVM_CAP_S390_USER_SIGP, there are only five Signal Processor orders (CONDITIONAL EMERGENCY SIGNAL, EMERGENCY SIGNAL, EXTERNAL CALL, SENSE, and SENSE RUNNING STATUS) which are intended for frequent use and thus are processed in-kernel. The remainder are sent to userspace with the KVM_CAP_S390_USER_SIGP capability. Of those, three orders (RESTART, STOP, and STOP AND STORE STATUS) have the potential to inject work back into the kernel, and thus are asynchronous. Let's look for those pending IRQs when processing one of the in-kernel SIGP orders, and return BUSY (CC2) if one is in process. This is in agreement with the Principles of Operation, which states that only one order can be "active" on a CPU at a time. Cc: stable@vger.kernel.org Suggested-by:
David Hildenbrand <david@redhat.com> Signed-off-by:
Eric Farman <farman@linux.ibm.com> Reviewed-by:
Christian Borntraeger <borntraeger@linux.ibm.com> Acked-by:
-
Sean Christopherson authored
commit ff083a2d upstream. Protect perf_guest_cbs with RCU to fix multiple possible errors. Luckily, all paths that read perf_guest_cbs already require RCU protection, e.g. to protect the callback chains, so only the direct perf_guest_cbs touchpoints need to be modified. Bug #1 is a simple lack of WRITE_ONCE/READ_ONCE behavior to ensure perf_guest_cbs isn't reloaded between a !NULL check and a dereference. Fixed via the READ_ONCE() in rcu_dereference(). Bug #2 is that on weakly-ordered architectures, updates to the callbacks themselves are not guaranteed to be visible before the pointer is made visible to readers. Fixed by the smp_store_release() in rcu_assign_pointer() when the new pointer is non-NULL. Bug #3 is that, because the callbacks are global, it's possible for readers to run in parallel with an unregisters, and thus a module implementing the callbacks can be unloaded while readers are in flight, resulting in a use-after-free. Fixed by a synchronize_rcu() call when unregistering callbacks. Bug #1 escaped notice because it's extremely unlikely a compiler will reload perf_guest_cbs in this sequence. perf_guest_cbs does get reloaded for future derefs, e.g. for ->is_user_mode(), but the ->is_in_guest() guard all but guarantees the consumer will win the race, e.g. to nullify perf_guest_cbs, KVM has to completely exit the guest and teardown down all VMs before KVM start its module unload / unregister sequence. This also makes it all but impossible to encounter bug #3. Bug #2 has not been a problem because all architectures that register callbacks are strongly ordered and/or have a static set of callbacks. But with help, unloading kvm_intel can trigger bug #1 e.g. wrapping perf_guest_cbs with READ_ONCE in perf_misc_flags() while spamming kvm_intel module load/unload leads to: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 6 PID: 1825 Comm: stress Not tainted 5.14.0-rc2+ #459 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:perf_misc_flags+0x1c/0x70 Call Trace: perf_prepare_sample+0x53/0x6b0 perf_event_output_forward+0x67/0x160 __perf_event_overflow+0x52/0xf0 handle_pmi_common+0x207/0x300 intel_pmu_handle_irq+0xcf/0x410 perf_event_nmi_handler+0x28/0x50 nmi_handle+0xc7/0x260 default_do_nmi+0x6b/0x170 exc_nmi+0x103/0x130 asm_exc_nmi+0x76/0xbf Fixes: 39447b38 ("perf: Enhance perf to allow for guest statistic collection from host") Signed-off-by:
Sean Christopherson <seanjc@google.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
-
Jamie Hill-Daniel authored
commit 722d9484 upstream. The "PAGE_SIZE - 2 - size" calculation in legacy_parse_param() is an unsigned type so a large value of "size" results in a high positive value instead of a negative value as expected. Fix this by getting rid of the subtraction. Signed-off-by:
Jamie Hill-Daniel <jamie@hill-daniel.co.uk> Signed-off-by:
William Liu <willsroot@protonmail.com> Tested-by:
Salvatore Bonaccorso <carnil@debian.org> Tested-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Christophe JAILLET authored
commit 40a74870 upstream. 'buffer_index_array' really looks like a bitmap. So it should be allocated as such. When kzalloc is called, a number of bytes is expected, but a number of longs is passed instead. In get(), if not enough memory is allocated, un-allocated memory may be read or written. So use bitmap_zalloc() to safely allocate the correct memory size and avoid un-expected behavior. While at it, change the corresponding kfree() into bitmap_free() to keep the semantic. Fixes: ea2c9c9f ("orangefs: bufmap rewrite") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Mike Marshall <hubcap@omnibond.com> Signed-off-by:
-
NeilBrown authored
commit a6097180 upstream. Prior to Linux v5.4 devtmpfs used mount_single() which treats the given mount options as "remount" options, so it updates the configuration of the single super_block on each mount. Since that was changed, the mount options used for devtmpfs are ignored. This is a regression which affect systemd - which mounts devtmpfs with "-o mode=755,size=4m,nr_inodes=1m". This patch restores the "remount" effect by calling reconfigure_single() Fixes: d401727e ("devtmpfs: don't mix {ramfs,shmem}_fill_super() with mount_single()") Acked-by:
Christian Brauner <christian.brauner@ubuntu.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Nathan Chancellor authored
commit f634ca65 upstream. Normally, invocations of $(HOSTCC) include $(KBUILD_HOSTLDFLAGS), which in turn includes $(HOSTLDFLAGS), which allows users to pass in their own flags when linking. However, the 'has_libelf' test does not, meaning that if a user requests a specific linker via HOSTLDFLAGS=-fuse-ld=..., it is not respected and the build might error. For example, if a user building with clang wants to use all of the LLVM tools without any GNU tools, they might remove all of the GNU tools from their system or PATH then build with $ make HOSTLDFLAGS=-fuse-ld=lld LLVM=1 LLVM_IAS=1 which says use all of the LLVM tools, the integrated assembler, and ld.lld for linking host executables. Without this change, the build will error because $(HOSTCC) uses its default linker, rather than the one requested via -fuse-ld=..., which is GNU ld in clang's case in a default configuration. error: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel make[1]: *** [Makefile:1260: prepare-objtool] Error 1 Add $(KBUILD_HOSTLDFLAGS) to the 'has_libelf' test so that the linker choice is respected. Link: https://github.com/ClangBuiltLinux/linux/issues/479 Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
Paul Barker <paul.barker@sancloud.com> Signed-off-by:
-
- Jan 16, 2022
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220114081541.465841464@linuxfoundation.org Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Tested-by:
-
Arnd Bergmann authored
commit 144779ed upstream. clang warns about excessive stack usage in this driver when UBSAN is enabled: drivers/staging/greybus/audio_topology.c:977:12: error: stack frame size of 1836 bytes in function 'gbaudio_tplg_create_widget' [-Werror,-Wframe-larger-than=] Rework this code to no longer use compound literals for initializing the structure in each case, but instead keep the common bits in a preallocated constant array and copy them as needed. Link: https://github.com/ClangBuiltLinux/linux/issues/1535 Link: https://lore.kernel.org/r/20210103223541.2790855-1-arnd@kernel.org/ Reviewed-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Nathan Chancellor authored
commit 2e705706 upstream. A new warning in clang points out a place in this file where a bitwise OR is being used with boolean types: drivers/gpu/drm/i915/intel_pm.c:3066:12: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical] changed = ilk_increase_wm_latency(dev_priv, dev_priv->wm.pri_latency, 12) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This construct is intentional, as it allows every one of the calls to ilk_increase_wm_latency() to occur (instead of short circuiting with logical OR) while still caring about the result of each call. To make this clearer to the compiler, use the '|=' operator to assign the result of each ilk_increase_wm_latency() call to changed, which keeps the meaning of the code the same but makes it obvious that every one of these calls is expected to happen. Link: https://github.com/ClangBuiltLinux/linux/issues/1473 Reported-by:
Dávid Bolvanský <david.bolvansky@gmail.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211014211916.3550122-1-nathan@kernel.org Signed-off-by:
-
Nathan Chancellor authored
commit 502408a6 upstream. A new warning in clang points out a place in this file where a bitwise OR is being used with boolean expressions: In file included from drivers/staging/wlan-ng/prism2usb.c:2: drivers/staging/wlan-ng/hfa384x_usb.c:3787:7: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical] ((test_and_clear_bit(THROTTLE_RX, &hw->usb_flags) && ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/staging/wlan-ng/hfa384x_usb.c:3787:7: note: cast one or both operands to int to silence this warning 1 warning generated. The comment explains that short circuiting here is undesirable, as the calls to test_and_{clear,set}_bit() need to happen for both sides of the expression. Clang's suggestion would work to silence the warning but the readability of the expression would suffer even more. To clean up the warning and make the block more readable, use a variable for each side of the bitwise expression. Link: https://github.com/ClangBuiltLinux/linux/issues/1478 Signed-off-by:
-
Ricardo Ribalda authored
commit f66dcb32 upstream. A lot of userspace depends on a descriptive name for vdev. Without this patch, users have a hard time figuring out which camera shall they use for their video conferencing. This reverts commit e3f60e7e. Link: https://lore.kernel.org/linux-media/20211207003840.1212374-2-ribalda@chromium.org Cc: <stable@vger.kernel.org> Fixes: e3f60e7e ("media: uvcvideo: Set unique vdev name based in type") Reported-by:
Nicolas Dufresne <nicolas@ndufresne.ca> Signed-off-by:
Ricardo Ribalda <ribalda@chromium.org> Reviewed-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Dominik Brodowski authored
commit f7e67b8e upstream. Currently, if CONFIG_RANDOM_TRUST_BOOTLOADER is enabled, multiple calls to add_bootloader_randomness() are broken and can cause a NULL pointer dereference, as noted by Ivan T. Ivanov. This is not only a hypothetical problem, as qemu on arm64 may provide bootloader entropy via EFI and via devicetree. On the first call to add_hwgenerator_randomness(), crng_fast_load() is executed, and if the seed is long enough, crng_init will be set to 1. On subsequent calls to add_bootloader_randomness() and then to add_hwgenerator_randomness(), crng_fast_load() will be skipped. Instead, wait_event_interruptible() and then credit_entropy_bits() will be called. If the entropy count for that second seed is large enough, that proceeds to crng_reseed(). However, both wait_event_interruptible() and crng_reseed() depends (at least in numa_crng_init()) on workqueues. Therefore, test whether system_wq is already initialized, which is a sufficient indicator that workqueue_init_early() has progressed far enough. If we wind up hitting the !system_wq case, we later want to do what would have been done there when wqs are up, so set a flag, and do that work later from the rand_initialize() call. Reported-by:
Ivan T. Ivanov <iivanov@suse.de> Fixes: 18b915ac ("efi/random: Treat EFI_RNG_PROTOCOL output as bootloader randomness") Cc: stable@vger.kernel.org Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.net> [Jason: added crng_need_done state and related logic.] Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Eric Biggers authored
commit 009ba856 upstream. _extract_crng() does plain loads of crng->init_time and crng_global_init_time, which causes undefined behavior if crng_reseed() and RNDRESEEDCRNG modify these corrently. Use READ_ONCE() and WRITE_ONCE() to make the behavior defined. Don't fix the race on crng->init_time by protecting it with crng->lock, since it's not a problem for duplicate reseedings to occur. I.e., the lockless access with READ_ONCE() is fine. Fixes: d848e5f8 ("random: add new ioctl RNDRESEEDCRNG") Fixes: e192be9d ("random: replace non-blocking pool with a Chacha20-based CRNG") Cc: stable@vger.kernel.org Signed-off-by:
Eric Biggers <ebiggers@google.com> Acked-by:
Paul E. McKenney <paulmck@kernel.org> Signed-off-by:
-
Eric Biggers authored
commit 5d73d1e3 upstream. extract_crng() and crng_backtrack_protect() load crng_node_pool with a plain load, which causes undefined behavior if do_numa_crng_init() modifies it concurrently. Fix this by using READ_ONCE(). Note: as per the previous discussion https://lore.kernel.org/lkml/20211219025139.31085-1-ebiggers@kernel.org/T/#u, READ_ONCE() is believed to be sufficient here, and it was requested that it be used here instead of smp_load_acquire(). Also change do_numa_crng_init() to set crng_node_pool using cmpxchg_release() instead of mb() + cmpxchg(), as the former is sufficient here but is more lightweight. Fixes: 1e7f583a ("random: make /dev/urandom scalable for silly userspace programs") Cc: stable@vger.kernel.org Signed-off-by:
-
Brian Silverman authored
commit 89d58aeb upstream. No information is deliberately sent in hf->flags in host -> device communications, but the open-source candleLight firmware echoes it back, which can result in the GS_CAN_FLAG_OVERFLOW flag being set and generating spurious ERRORFRAMEs. While there also initialize the reserved member with 0. Fixes: d08e973a ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://lore.kernel.org/all/20220106002952.25883-1-brian.silverman@bluerivertech.com Link: https://github.com/candle-usb/candleLight_fw/issues/87 Cc: stable@vger.kernel.org Signed-off-by:
Brian Silverman <brian.silverman@bluerivertech.com> [mkl: initialize the reserved member, too] Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Marc Kleine-Budde authored
commit 4a8737ff upstream. The received data contains the channel the received data is associated with. If the channel number is bigger than the actual number of channels assume broken or malicious USB device and shut it down. This fixes the error found by clang: | drivers/net/can/usb/gs_usb.c:386:6: error: variable 'dev' is used | uninitialized whenever 'if' condition is true | if (hf->channel >= GS_MAX_INTF) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ | drivers/net/can/usb/gs_usb.c:474:10: note: uninitialized use occurs here | hf, dev->gs_hf_size, gs_usb_receive_bulk_callback, | ^~~ Link: https://lore.kernel.org/all/20211210091158.408326-1-mkl@pengutronix.de Fixes: d08e973a ("can: gs_usb: Added support for the GS_USB CAN devices") Cc: stable@vger.kernel.org Signed-off-by:
-
Joe Perches authored
commit aa838896 upstream. Convert the various sprintf fmaily calls in sysfs device show functions to sysfs_emit and sysfs_emit_at for PAGE_SIZE buffer safety. Done with: $ spatch -sp-file sysfs_emit_dev.cocci --in-place --max-width=80 . And cocci script: $ cat sysfs_emit_dev.cocci @@ identifier d_show; identifier dev, attr, buf; @@ ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... return - sprintf(buf, + sysfs_emit(buf, ...); ...> } @@ identifier d_show; identifier dev, attr, buf; @@ ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... return - snprintf(buf, PAGE_SIZE, + sysfs_emit(buf, ...); ...> } @@ identifier d_show; identifier dev, attr, buf; @@ ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... return - scnprintf(buf, PAGE_SIZE, + sysfs_emit(buf, ...); ...> } @@ identifier d_show; identifier dev, attr, buf; expression chr; @@ ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... return - strcpy(buf, chr); + sysfs_emit(buf, chr); ...> } @@ identifier d_show; identifier dev, attr, buf; identifier len; @@ ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... len = - sprintf(buf, + sysfs_emit(buf, ...); ...> return len; } @@ identifier d_show; identifier dev, attr, buf; identifier len; @@ ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... len = - snprintf(buf, PAGE_SIZE, + sysfs_emit(buf, ...); ...> return len; } @@ identifier d_show; identifier dev, attr, buf; identifier len; @@ ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... len = - scnprintf(buf, PAGE_SIZE, + sysfs_emit(buf, ...); ...> return len; } @@ identifier d_show; identifier dev, attr, buf; identifier len; @@ ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... - len += scnprintf(buf + len, PAGE_SIZE - len, + len += sysfs_emit_at(buf, len, ...); ...> return len; } @@ identifier d_show; identifier dev, attr, buf; expression chr; @@ ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { ... - strcpy(buf, chr); - return strlen(buf); + return sysfs_emit(buf, chr); } Signed-off-by:
Joe Perches <joe@perches.com> Link: https://lore.kernel.org/r/3d033c33056d88bbe34d4ddb62afd05ee166ab9a.1600285923.git.joe@perches.com Cc: Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Andy Shevchenko authored
commit c9e14308 upstream. The runtime PM callback may be called as soon as the runtime PM facility is enabled and activated. It means that ->suspend() may be called before we finish probing the device in the ACPI case. Hence, NULL pointer dereference: intel-lpss INT34BA:00: IRQ index 0 not found BUG: kernel NULL pointer dereference, address: 0000000000000030 ... Workqueue: pm pm_runtime_work RIP: 0010:intel_lpss_suspend+0xb/0x40 [intel_lpss] To fix this, first try to register the device and only after that enable runtime PM facility. Fixes: 4b45efe8 ("mfd: Add support for Intel Sunrisepoint LPSS devices") Reported-by:
Orlando Chamberlain <redecorating@protonmail.com> Reported-by:
Aditya Garg <gargaditya08@live.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by:
Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20211101190008.86473-1-andriy.shevchenko@linux.intel.com Signed-off-by:
-
Daniel Borkmann authored
commit 710ad98c upstream. Laurent reported that they have seen a significant amount of TCP retransmissions at high throughput from applications residing in network namespaces talking to the outside world via veths. The drops were seen on the qdisc layer (fq_codel, as per systemd default) of the phys device such as ena or virtio_net due to all traffic hitting a _single_ TX queue _despite_ multi-queue device. (Note that the setup was _not_ using XDP on veths as the issue is generic.) More specifically, after edbea922 ("veth: Store queue_mapping independently of XDP prog presence") which made it all the way back to v4.19.184+, skb_record_rx_queue() would set skb->queue_mapping to 1 (given 1 RX and 1 TX queue by default for veths) instead of leaving at 0. This is eventually retained and callbacks like ena_select_queue() will also pick single queue via netdev_core_pick_tx()'s ndo_select_queue() once all the traffic is forwarded to that device via upper stack or other means. Similarly, for others not implementing ndo_select_queue() if XPS is disabled, netdev_pick_tx() might call into the skb_tx_hash() and check for prior skb_rx_queue_recorded() as well. In general, it is a _bad_ idea for virtual devices like veth to mess around with queue selection [by default]. Given dev->real_num_tx_queues is by default 1, the skb->queue_mapping was left untouched, and so prior to edbea922 the netdev_core_pick_tx() could do its job upon __dev_queue_xmit() on the phys device. Unbreak this and restore prior behavior by removing the skb_record_rx_queue() from veth_xmit() altogether. If the veth peer has an XDP program attached, then it would return the first RX queue index in xdp_md->rx_queue_index (unless configured in non-default manner). However, this is still better than breaking the generic case. Fixes: edbea922 ("veth: Store queue_mapping independently of XDP prog presence") Fixes: 638264dc ("veth: Support per queue XDP ring") Reported-by:
Laurent Bernaille <laurent.bernaille@datadoghq.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Cc: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Cc: Toshiaki Makita <toshiaki.makita1@gmail.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Paolo Abeni <pabeni@redhat.com> Cc: John Fastabend <john.fastabend@gmail.com> Cc: Willem de Bruijn <willemb@google.com> Acked-by:
John Fastabend <john.fastabend@gmail.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Toshiaki Makita <toshiaki.makita1@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Adrian Hunter authored
commit e53e97f8 upstream. Add PCI ID for Intel ADL eMMC host controller. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20211124094850.1783220-1-adrian.hunter@intel.com Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Alan Stern authored
commit 1d7d4c07 upstream. When the USB core code for getting root-hub status reports was originally written, it was assumed that the hub driver would be its only caller. But this isn't true now; user programs can use usbfs to communicate with root hubs and get status reports. When they do this, they may use a transfer_buffer that is smaller than the data returned by the HCD, which will lead to a buffer overflow error when usb_hcd_poll_rh_status() tries to store the status data. This was discovered by syzbot: BUG: KASAN: slab-out-of-bounds in memcpy include/linux/fortify-string.h:225 [inline] BUG: KASAN: slab-out-of-bounds in usb_hcd_poll_rh_status+0x5f4/0x780 drivers/usb/core/hcd.c:776 Write of size 2 at addr ffff88801da403c0 by task syz-executor133/4062 This patch fixes the bug by reducing the amount of status data if it won't fit in the transfer_buffer. If some data gets discarded then the URB's completion status is set to -EOVERFLOW rather than 0, to let the user know what happened. Reported-and-tested-by:
<syzbot+3ae6a2b06f131ab9849f@syzkaller.appspotmail.com> Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/Yc+3UIQJ2STbxNua@rowland.harvard.edu Signed-off-by:
-
Alan Stern authored
commit 0f663729 upstream. Bugzilla #213839 reports a 7-port hub that doesn't work properly when devices are plugged into some of the ports; the kernel goes into an unending disconnect/reinitialize loop as shown in the bug report. This "7-port hub" comprises two four-port hubs with one plugged into the other; the failures occur when a device is plugged into one of the downstream hub's ports. (These hubs have other problems too. For example, they bill themselves as USB-2.0 compliant but they only run at full speed.) It turns out that the failures are caused by bugs in both the kernel and the hub. The hub's bug is that it reports a different bmAttributes value in its configuration descriptor following a remote wakeup (0xe0 before, 0xc0 after -- the wakeup-support bit has changed). The kernel's bug is inside the hub driver's resume handler. When hub_activate() sees that one of the hub's downstream ports got a wakeup request from a child device, it notes this fact by setting the corresponding bit in the hub->change_bits variable. But this variable is meant for connection changes, not wakeup events; setting it causes the driver to believe the downstream port has been disconnected and then connected again (in addition to having received a wakeup request). Because of this, the hub driver then tries to check whether the device currently plugged into the downstream port is the same as the device that had been attached there before. Normally this check succeeds and wakeup handling continues with no harm done (which is why the bug remained undetected until now). But with these dodgy hubs, the check fails because the config descriptor has changed. This causes the hub driver to reinitialize the child device, leading to the disconnect/reinitialize loop described in the bug report. The proper way to note reception of a downstream wakeup request is to set a bit in the hub->event_bits variable instead of hub->change_bits. That way the hub driver will realize that something has happened to the port but will not think the port and child device have been disconnected. This patch makes that change. Cc: <stable@vger.kernel.org> Tested-by:
Jonathan McDowell <noodles@earth.li> Signed-off-by:
-
Johan Hovold authored
commit b5e6fa7a upstream. Add the missing bulk-out endpoint sanity check to probe() to avoid division by zero in bfusb_send_frame() in case a malicious device has broken descriptors (or when doing descriptor fuzz testing). Note that USB core will reject URBs submitted for endpoints with zero wMaxPacketSize but that drivers doing packet-size calculations still need to handle this (cf. commit 2548288b ("USB: Fix: Don't skip endpoint descriptors with maxpacket=0")). Cc: stable@vger.kernel.org Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Mark-YW.Chen authored
commit 60c6a63a upstream. Driver should free `usb->setup_packet` to avoid the leak. $ cat /sys/kernel/debug/kmemleak unreferenced object 0xffffffa564a58080 (size 128): backtrace: [<000000007eb8dd70>] kmem_cache_alloc_trace+0x22c/0x384 [<000000008a44191d>] btusb_mtk_hci_wmt_sync+0x1ec/0x994 [btusb] [<00000000ca7189a3>] btusb_mtk_setup+0x6b8/0x13cc [btusb] [<00000000c6105069>] hci_dev_do_open+0x290/0x974 [bluetooth] [<00000000a583f8b8>] hci_power_on+0xdc/0x3cc [bluetooth] [<000000005d80e687>] process_one_work+0x514/0xc80 [<00000000f4d57637>] worker_thread+0x818/0xd0c [<00000000dc7bdb55>] kthread+0x2f8/0x3b8 [<00000000f9999513>] ret_from_fork+0x10/0x30 Fixes: a1c49c43 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices") Signed-off-by:
Mark-YW.Chen <mark-yw.chen@mediatek.com> Signed-off-by:
-
Frederic Weisbecker authored
commit 07edfece upstream. At CPU-hotplug time, unbind_worker() may preempt a worker while it is waking up. In that case the following scenario can happen: unbind_workers() wq_worker_running() -------------- ------------------- if (!(worker->flags & WORKER_NOT_RUNNING)) //PREEMPTED by unbind_workers worker->flags |= WORKER_UNBOUND; [...] atomic_set(&pool->nr_running, 0); //resume to worker atomic_inc(&worker->pool->nr_running); After unbind_worker() resets pool->nr_running, the value is expected to remain 0 until the pool ever gets rebound in case cpu_up() is called on the target CPU in the future. But here the race leaves pool->nr_running with a value of 1, triggering the following warning when the worker goes idle: WARNING: CPU: 3 PID: 34 at kernel/workqueue.c:1823 worker_enter_idle+0x95/0xc0 Modules linked in: CPU: 3 PID: 34 Comm: kworker/3:0 Not tainted 5.16.0-rc1+ #34 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014 Workqueue: 0x0 (rcu_par_gp) RIP: 0010:worker_enter_idle+0x95/0xc0 Code: 04 85 f8 ff ff ff 39 c1 7f 09 48 8b 43 50 48 85 c0 74 1b 83 e2 04 75 99 8b 43 34 39 43 30 75 91 8b 83 00 03 00 00 85 c0 74 87 <0f> 0b 5b c3 48 8b 35 70 f1 37 01 48 8d 7b 48 48 81 c6 e0 93 0 RSP: 0000:ffff9b7680277ed0 EFLAGS: 00010086 RAX: 00000000ffffffff RBX: ffff93465eae9c00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9346418a0000 RDI: ffff934641057140 RBP: ffff934641057170 R08: 0000000000000001 R09: ffff9346418a0080 R10: ffff9b768027fdf0 R11: 0000000000002400 R12: ffff93465eae9c20 R13: ffff93465eae9c20 R14: ffff93465eae9c70 R15: ffff934641057140 FS: 0000000000000000(0000) GS:ffff93465eac0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000001cc0c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> worker_thread+0x89/0x3d0 ? process_one_work+0x400/0x400 kthread+0x162/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 </TASK> Also due to this incorrect "nr_running == 1", further queued work may end up not being served, because no worker is awaken at work insert time. This raises rcutorture writer stalls for example. Fix this with disabling preemption in the right place in wq_worker_running(). It's worth noting that if the worker migrates and runs concurrently with unbind_workers(), it is guaranteed to see the WORKER_UNBOUND flag update due to set_cpus_allowed_ptr() acquiring/releasing rq->lock. Fixes: 6d25be57 ("sched/core, workqueues: Distangle worker accounting from rq lock") Reviewed-by:
Lai Jiangshan <jiangshanlai@gmail.com> Tested-by:
Frederic Weisbecker <frederic@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Daniel Bristot de Oliveira <bristot@redhat.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
- Jan 11, 2022
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220110071815.647309738@linuxfoundation.org Tested-by:
-
wolfgang huang authored
[ Upstream commit 8b5fdfc5 ] As we build for mips, we meet following error. l1_init error with multiple definition. Some architecture devices usually marked with l1, l2, lxx as the start-up phase. so we change the mISDN function names, align with Isdnl2_xxx. mips-linux-gnu-ld: drivers/isdn/mISDN/layer1.o: in function `l1_init': (.text+0x890): multiple definition of `l1_init'; \ arch/mips/kernel/bmips_5xxx_init.o:(.text+0xf0): first defined here make[1]: *** [home/mips/kernel-build/linux/Makefile:1161: vmlinux] Error 1 Signed-off-by:
wolfgang huang <huangjinhui@kylinos.cn> Reported-by:
k2ci <kernel-bot@kylinos.cn> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Zekun Shen authored
[ Upstream commit 5f501532 ] The function obtain the next buffer without boundary check. We should return with I/O error code. The bug is found by fuzzing and the crash report is attached. It is an OOB bug although reported as use-after-free. [ 4.804724] BUG: KASAN: use-after-free in aq_ring_rx_clean+0x1e88/0x2730 [atlantic] [ 4.805661] Read of size 4 at addr ffff888034fe93a8 by task ksoftirqd/0/9 [ 4.806505] [ 4.806703] CPU: 0 PID: 9 Comm: ksoftirqd/0 Tainted: G W 5.6.0 #34 [ 4.809030] Call Trace: [ 4.809343] dump_stack+0x76/0xa0 [ 4.809755] print_address_description.constprop.0+0x16/0x200 [ 4.810455] ? aq_ring_rx_clean+0x1e88/0x2730 [atlantic] [ 4.811234] ? aq_ring_rx_clean+0x1e88/0x2730 [atlantic] [ 4.813183] __kasan_report.cold+0x37/0x7c [ 4.813715] ? aq_ring_rx_clean+0x1e88/0x2730 [atlantic] [ 4.814393] kasan_report+0xe/0x20 [ 4.814837] aq_ring_rx_clean+0x1e88/0x2730 [atlantic] [ 4.815499] ? hw_atl_b0_hw_ring_rx_receive+0x9a5/0xb90 [atlantic] [ 4.816290] aq_vec_poll+0x179/0x5d0 [atlantic] [ 4.816870] ? _GLOBAL__sub_I_65535_1_aq_pci_func_init+0x20/0x20 [atlantic] [ 4.817746] ? __next_timer_interrupt+0xba/0xf0 [ 4.818322] net_rx_action+0x363/0xbd0 [ 4.818803] ? call_timer_fn+0x240/0x240 [ 4.819302] ? __switch_to_asm+0x40/0x70 [ 4.819809] ? napi_busy_loop+0x520/0x520 [ 4.820324] __do_softirq+0x18c/0x634 [ 4.820797] ? takeover_tasklets+0x5f0/0x5f0 [ 4.821343] run_ksoftirqd+0x15/0x20 [ 4.821804] smpboot_thread_fn+0x2f1/0x6b0 [ 4.822331] ? smpboot_unregister_percpu_thread+0x160/0x160 [ 4.823041] ? __kthread_parkme+0x80/0x100 [ 4.823571] ? smpboot_unregister_percpu_thread+0x160/0x160 [ 4.824301] kthread+0x2b5/0x3b0 [ 4.824723] ? kthread_create_on_node+0xd0/0xd0 [ 4.825304] ret_from_fork+0x35/0x40 Signed-off-by:
Zekun Shen <bruceshenzk@gmail.com> Signed-off-by:
-
yangxingwu authored
[ Upstream commit 6c25449e ] $ cat /pro/net/udp before: sl local_address rem_address st tx_queue rx_queue tr tm->when 26050: 0100007F:0035 00000000:0000 07 00000000:00000000 00:00000000 26320: 0100007F:0143 00000000:0000 07 00000000:00000000 00:00000000 27135: 00000000:8472 00000000:0000 07 00000000:00000000 00:00000000 after: sl local_address rem_address st tx_queue rx_queue tr tm->when 26050: 0100007F:0035 00000000:0000 07 00000000:00000000 00:00000000 26320: 0100007F:0143 00000000:0000 07 00000000:00000000 00:00000000 27135: 00000000:8472 00000000:0000 07 00000000:00000000 00:00000000 Signed-off-by:
yangxingwu <xingwu.yang@gmail.com> Signed-off-by:
-
William Zhao authored
[ Upstream commit c1833c39 ] The "__ip6_tnl_parm" struct was left uninitialized causing an invalid load of random data when the "__ip6_tnl_parm" struct was used elsewhere. As an example, in the function "ip6_tnl_xmit_ctl()", it tries to access the "collect_md" member. With "__ip6_tnl_parm" being uninitialized and containing random data, the UBSAN detected that "collect_md" held a non-boolean value. The UBSAN issue is as follows: =============================================================== UBSAN: invalid-load in net/ipv6/ip6_tunnel.c:1025:14 load of value 30 is not a valid value for type '_Bool' CPU: 1 PID: 228 Comm: kworker/1:3 Not tainted 5.16.0-rc4+ #8 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 Workqueue: ipv6_addrconf addrconf_dad_work Call Trace: <TASK> dump_stack_lvl+0x44/0x57 ubsan_epilogue+0x5/0x40 __ubsan_handle_load_invalid_value+0x66/0x70 ? __cpuhp_setup_state+0x1d3/0x210 ip6_tnl_xmit_ctl.cold.52+0x2c/0x6f [ip6_tunnel] vti6_tnl_xmit+0x79c/0x1e96 [ip6_vti] ? lock_is_held_type+0xd9/0x130 ? vti6_rcv+0x100/0x100 [ip6_vti] ? lock_is_held_type+0xd9/0x130 ? rcu_read_lock_bh_held+0xc0/0xc0 ? lock_acquired+0x262/0xb10 dev_hard_start_xmit+0x1e6/0x820 __dev_queue_xmit+0x2079/0x3340 ? mark_lock.part.52+0xf7/0x1050 ? netdev_core_pick_tx+0x290/0x290 ? kvm_clock_read+0x14/0x30 ? kvm_sched_clock_read+0x5/0x10 ? sched_clock_cpu+0x15/0x200 ? find_held_lock+0x3a/0x1c0 ? lock_release+0x42f/0xc90 ? lock_downgrade+0x6b0/0x6b0 ? mark_held_locks+0xb7/0x120 ? neigh_connected_output+0x31f/0x470 ? lockdep_hardirqs_on+0x79/0x100 ? neigh_connected_output+0x31f/0x470 ? ip6_finish_output2+0x9b0/0x1d90 ? rcu_read_lock_bh_held+0x62/0xc0 ? ip6_finish_output2+0x9b0/0x1d90 ip6_finish_output2+0x9b0/0x1d90 ? ip6_append_data+0x330/0x330 ? ip6_mtu+0x166/0x370 ? __ip6_finish_output+0x1ad/0xfb0 ? nf_hook_slow+0xa6/0x170 ip6_output+0x1fb/0x710 ? nf_hook.constprop.32+0x317/0x430 ? ip6_finish_output+0x180/0x180 ? __ip6_finish_output+0xfb0/0xfb0 ? lock_is_held_type+0xd9/0x130 ndisc_send_skb+0xb33/0x1590 ? __sk_mem_raise_allocated+0x11cf/0x1560 ? dst_output+0x4a0/0x4a0 ? ndisc_send_rs+0x432/0x610 addrconf_dad_completed+0x30c/0xbb0 ? addrconf_rs_timer+0x650/0x650 ? addrconf_dad_work+0x73c/0x10e0 addrconf_dad_work+0x73c/0x10e0 ? addrconf_dad_completed+0xbb0/0xbb0 ? rcu_read_lock_sched_held+0xaf/0xe0 ? rcu_read_lock_bh_held+0xc0/0xc0 process_one_work+0x97b/0x1740 ? pwq_dec_nr_in_flight+0x270/0x270 worker_thread+0x87/0xbf0 ? process_one_work+0x1740/0x1740 kthread+0x3ac/0x490 ? set_kthread_struct+0x100/0x100 ret_from_fork+0x22/0x30 </TASK> =============================================================== The solution is to initialize "__ip6_tnl_parm" struct to zeros in the "vti6_siocdevprivate()" function. Signed-off-by:
William Zhao <wizhao@redhat.com> Signed-off-by:
-
