- Apr 21, 2021
-
-
Greg Kroah-Hartman authored
Tested-by:
Fox Chen <foxhlchen@gmail.com> Tested-by:
Jason Self <jason@bluehome.net> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Link: https://lore.kernel.org/r/20210419130530.166331793@linuxfoundation.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Daniel Borkmann authored
commit f5288193 upstream. Add a small sanitize_needed() helper function and move sanitize_val_alu() out of the main opcode switch. In upcoming work, we'll move sanitize_ptr_alu() as well out of its opcode switch so this helps to streamline both. Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Reviewed-by:
John Fastabend <john.fastabend@gmail.com> Acked-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Daniel Borkmann authored
commit a6aaece0 upstream. Consolidate all error handling and provide more user-friendly error messages from sanitize_ptr_alu() and sanitize_val_alu(). Signed-off-by:
-
Daniel Borkmann authored
commit b658bbb8 upstream. Small refactor with no semantic changes in order to consolidate the max ptr_limit boundary check. Signed-off-by:
-
Fredrik Strupe authored
commit d2f7eca6 upstream. Since uprobes is not supported for thumb, check that the thumb bit is not set when matching the uprobes instruction hooks. The Arm UDF instructions used for uprobes triggering (UPROBE_SWBP_ARM_INSN and UPROBE_SS_ARM_INSN) coincidentally share the same encoding as a pair of unallocated 32-bit thumb instructions (not UDF) when the condition code is 0b1111 (0xf). This in effect makes it possible to trigger the uprobes functionality from thumb, and at that using two unallocated instructions which are not permanently undefined. Signed-off-by:
Fredrik Strupe <fredrik@strupe.net> Cc: stable@vger.kernel.org Fixes: c7edc9e3 ("ARM: add uprobes support") Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit 6f55b2f2 ] Small refactor to drag off_reg into sanitize_ptr_alu(), so we later on can use off_reg for generalizing some of the checks for all pointer types. Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Daniel Borkmann authored
[ Upstream commit 24c109bb ] The mixed signed bounds check really belongs into retrieve_ptr_limit() instead of outside of it in adjust_ptr_min_max_vals(). The reason is that this check is not tied to PTR_TO_MAP_VALUE only, but to all pointer types that we handle in retrieve_ptr_limit() and given errors from the latter propagate back to adjust_ptr_min_max_vals() and lead to rejection of the program, it's a better place to reside to avoid anything slipping through for future types. The reason why we must reject such off_reg is that we otherwise would not be able to derive a mask, see details in 9d7eceed ("bpf: restrict unknown scalars of mixed signed bounds for unprivileged"). Signed-off-by:
-
Heiner Kallweit authored
[ Upstream commit 453a7789 ] It has been reported [0] that using pause frames in jumbo mode impacts performance. There's no available chip documentation, but vendor drivers r8168 and r8125 don't advertise pause in jumbo mode. So let's do the same, according to Roman it fixes the issue. [0] https://bugzilla.kernel.org/show_bug.cgi?id=212617 Fixes: 9cf9b84c ("r8169: make use of phy_set_asym_pause") Reported-by:
Roman Mamedov <rm+bko@romanrm.net> Tested-by:
Heiner Kallweit <hkallweit1@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Heiner Kallweit authored
[ Upstream commit 5e00e16c ] So far we don't increase the max read request size if we switch to jumbo mode before bringing up the interface for the first time. Let's change this. Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Walter Wu authored
[ Upstream commit 02c58773 ] CONFIG_KASAN_STACK and CONFIG_KASAN_STACK_ENABLE both enable KASAN stack instrumentation, but we should only need one config, so that we remove CONFIG_KASAN_STACK_ENABLE and make CONFIG_KASAN_STACK workable. see [1]. When enable KASAN stack instrumentation, then for gcc we could do no prompt and default value y, and for clang prompt and default value n. This patch fixes the following compilation warning: include/linux/kasan.h:333:30: warning: 'CONFIG_KASAN_STACK' is not defined, evaluates to 0 [-Wundef] [akpm@linux-foundation.org: fix merge snafu] Link: https://bugzilla.kernel.org/show_bug.cgi?id=210221 [1] Link: https://lkml.kernel.org/r/20210226012531.29231-1-walter-zh.wu@mediatek.com Fixes: d9b571c8 ("kasan: fix KASAN_STACK dependency for HW_TAGS") Signed-off-by:
Walter Wu <walter-zh.wu@mediatek.com> Suggested-by:
Dmitry Vyukov <dvyukov@google.com> Reviewed-by:
Nathan Chancellor <natechancellor@gmail.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Andrey Konovalov <andreyknvl@google.com> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Alexander Potapenko <glider@google.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 5c595ac4 ] gcc-11 adds support for -fsanitize=kernel-hwaddress, so it becomes possible to enable CONFIG_KASAN_SW_TAGS. Unfortunately this fails to build at the moment, because the corresponding command line arguments use llvm specific syntax. Change it to use the cc-param macro instead, which works on both clang and gcc. [elver@google.com: fixup for "kasan: fix hwasan build for gcc"] Link: https://lkml.kernel.org/r/YHQZVfVVLE/LDK2v@elver.google.com Link: https://lkml.kernel.org/r/20210323124112.1229772-1-arnd@kernel.org Signed-off-by:
Marco Elver <elver@google.com> Reviewed-by:
Andrey Konovalov <andreyknvl@gmail.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
-
Reiji Watanabe authored
[ Upstream commit 04c4f2ee ] __vmx_handle_exit() uses vcpu->run->internal.ndata as an index for an array access. Since vcpu->run is (can be) mapped to a user address space with a writer permission, the 'ndata' could be updated by the user process at anytime (the user process can set it to outside the bounds of the array). So, it is not safe that __vmx_handle_exit() uses the 'ndata' that way. Fixes: 1aa561b1 ("kvm: x86: Add "last CPU" to some KVM_EXIT information") Signed-off-by:
Reiji Watanabe <reijiw@google.com> Reviewed-by:
Jim Mattson <jmattson@google.com> Message-Id: <20210413154739.490299-1-reijiw@google.com> Cc: stable@vger.kernel.org Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Sean Christopherson authored
[ Upstream commit 8e533240 ] Convert vcpu_vmx.exit_reason from a u32 to a union (of size u32). The full VM_EXIT_REASON field is comprised of a 16-bit basic exit reason in bits 15:0, and single-bit modifiers in bits 31:16. Historically, KVM has only had to worry about handling the "failed VM-Entry" modifier, which could only be set in very specific flows and required dedicated handling. I.e. manually stripping the FAILED_VMENTRY bit was a somewhat viable approach. But even with only a single bit to worry about, KVM has had several bugs related to comparing a basic exit reason against the full exit reason store in vcpu_vmx. Upcoming Intel features, e.g. SGX, will add new modifier bits that can be set on more or less any VM-Exit, as opposed to the significantly more restricted FAILED_VMENTRY, i.e. correctly handling everything in one-off flows isn't scalable. Tracking exit reason in a union forces code to explicitly choose between consuming the full exit reason and the basic exit, and is a convenient way to document and access the modifiers. No functional change intended. Cc: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by:
Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by:
Chenyi Qiang <chenyi.qiang@intel.com> Message-Id: <20201106090315.18606-2-chenyi.qiang@intel.com> Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit 96011483 ] We forbid adding unknown scalars with mixed signed bounds due to the spectre v1 masking mitigation. Hence this also needs bypass_spec_v1 flag instead of allow_ptr_leaks. Fixes: 2c78ee89 ("bpf: Implement CAP_BPF") Signed-off-by:
-
Jernej Skrabec authored
[ Upstream commit 7a2f6e69 ] Although every Beelink GS1 seems to have external 32768 Hz oscillator, it works only on one from four tested. There are more reports of RTC issues elsewhere, like Armbian forum. One Beelink GS1 owner read RTC osc status register on Android which shipped with the box. Reported value indicated problems with external oscillator. In order to fix RTC and related issues (HDMI-CEC and suspend/resume with Crust) on all boards, switch to internal oscillator. Fixes: 32507b86 ("arm64: dts: allwinner: h6: Move ext. oscillator to board DTs") Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> Tested-by:
Clément Péron <peron.clem@gmail.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210330184218.279738-1-jernej.skrabec@siol.net Signed-off-by:
-
Andre Przywara authored
[ Upstream commit 3dd4ce41 ] Commit 941432d0 ("arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD card") enabled the card detect GPIO for the SOPine module, along the way with the Pine64-LTS, which share the same base .dtsi. However while both boards indeed have a working CD GPIO on PF6, the polarity is different: the SOPine modules uses a "push-pull" socket, which has an active-high switch, while the Pine64-LTS use the more traditional push-push socket and the common active-low switch. Fix the polarity in the sopine.dtsi, and overwrite it in the LTS board .dts, to make the SD card work again on systems using SOPine modules. Fixes: 941432d0 ("arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD card") Reported-by:
Ashley <contact@victorianfox.com> Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit fc85dc42 ] Fix uninitialized sr_inst. Fixes: fbfa463b ("ARM: OMAP2+: Fix smartreflex init regression after dropping legacy data") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Russell King authored
[ Upstream commit 30e3b4f2 ] Since commit 30fdfb92 ("PCI: Add a call to pci_assign_irq() in pci_device_probe()"), the PCI code will call the IRQ mapping function whenever a PCI driver is probed. If these are marked as __init, this causes an oops if a PCI driver is loaded or bound after the kernel has initialised. Fixes: 30fdfb92 ("PCI: Add a call to pci_assign_irq() in pci_device_probe()") Signed-off-by:
-
Vladimir Murzin authored
[ Upstream commit 45c2f70c ] for_each_mem_range() uses a loop variable, yet looking into code it is not just iteration counter but more complex entity which encodes information about memblock. Thus condition i == 0 looks fragile. Indeed, it broke boot of R-class platforms since it never took i == 0 path (due to i was set to 1). Fix that with restoring original flag check. Fixes: b10d6bca ("arch, drivers: replace for_each_membock() with for_each_mem_range()") Signed-off-by:
Vladimir Murzin <vladimir.murzin@arm.com> Acked-by:
Mike Rapoport <rppt@linux.ibm.com> Signed-off-by:
-
Ard Biesheuvel authored
[ Upstream commit d624833f ] The debugging code for kmap_local() doubles the number of per-CPU fixmap slots allocated for kmap_local(), in order to use half of them as guard regions. This causes the fixmap region to grow downwards beyond the start of its reserved window if the supported number of CPUs is large, and collide with the newly added virtual DT mapping right below it, which is obviously not good. One manifestation of this is EFI boot on a kernel built with NR_CPUS=32 and CONFIG_DEBUG_KMAP_LOCAL=y, which may pass the FDT in highmem, resulting in block entries below the fixmap region that the fixmap code misidentifies as fixmap table entries, and subsequently tries to dereference using a phys-to-virt translation that is only valid for lowmem. This results in a cryptic splat such as the one below. ftrace: allocating 45548 entries in 89 pages 8<--- cut here --- Unable to handle kernel paging request at virtual address fc6006f0 pgd = (ptrval) [fc6006f0] *pgd=80000040207003, *pmd=00000000 Internal error: Oops: a06 [#1] SMP ARM Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.11.0+ #382 Hardware name: Generic DT based system PC is at cpu_ca15_set_pte_ext+0x24/0x30 LR is at __set_fixmap+0xe4/0x118 pc : [<c041ac9c>] lr : [<c04189d8>] psr: 400000d3 sp : c1601ed8 ip : 00400000 fp : 00800000 r10: 0000071f r9 : 00421000 r8 : 00c00000 r7 : 00c00000 r6 : 0000071f r5 : ffade000 r4 : 4040171f r3 : 00c00000 r2 : 4040171f r1 : c041ac78 r0 : fc6006f0 Flags: nZcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none Control: 30c5387d Table: 40203000 DAC: 00000001 Process swapper (pid: 0, stack limit = 0x(ptrval)) So let's limit CONFIG_NR_CPUS to 16 when CONFIG_DEBUG_KMAP_LOCAL=y. Also, fix the BUILD_BUG_ON() check that was supposed to catch this, by checking whether the region grows below the start address rather than above the end address. Fixes: 2a15ba82 ("ARM: highmem: Switch to generic kmap atomic") Reported-by:
Peter Robinson <pbrobinson@gmail.com> Tested-by:
Ard Biesheuvel <ardb@kernel.org> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit a3efe3f6 ] Fix warning: no previous prototype for 'omap_init_time_of'. Fixes: e69b4e1a ("ARM: OMAP2+: Add omap_init_time_of()") Reported-by:
-
Eric Dumazet authored
commit 38ec4944 upstream. After commit 0f6925b3 ("virtio_net: Do not pull payload in skb->head") Guenter Roeck reported one failure in his tests using sh architecture. After much debugging, we have been able to spot silent unaligned accesses in inet_gro_receive() The issue at hand is that upper networking stacks assume their header is word-aligned. Low level drivers are supposed to reserve NET_IP_ALIGN bytes before the Ethernet header to make that happen. This patch hardens skb_gro_reset_offset() to not allow frag0 fast-path if the fragment is not properly aligned. Some arches like x86, arm64 and powerpc do not care and define NET_IP_ALIGN as 0, this extra check will be a NOP for them. Note that if frag0 is not used, GRO will call pskb_may_pull() as many times as needed to pull network and transport headers. Fixes: 0f6925b3 ("virtio_net: Do not pull payload in skb->head") Fixes: 78a478d0 ("gro: Inline skb_gro_header and cache frag0 virtual address") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Michael S. Tsirkin <mst@redhat.com> Tested-by:
-
Vinay Kumar Yadav authored
commit e8a41555 upstream. snd_una update should not be done when the same skb is being sent out.chcr_short_record_handler() sends it again even though SND_UNA update is already sent for the skb in chcr_ktls_xmit(), which causes mismatch in un-acked TCP seq number, later causes problem in sending out complete record. Fixes: 429765a1 ("chcr: handle partial end part of a record") Signed-off-by:
Vinay Kumar Yadav <vinay.yadav@chelsio.com> Signed-off-by:
Rohit Maheshwari <rohitm@chelsio.com> Signed-off-by:
-
Vinay Kumar Yadav authored
commit 21d8c25e upstream. HW doesn't need marking TCB closed. This TCB state change sometimes causes problem to the new connection which gets the same tid. Fixes: 34aba2c4 ("cxgb4/chcr : Register to tls add and del callback") Signed-off-by:
-
Vinay Kumar Yadav authored
commit bc16efd2 upstream. When sge queue is full and chcr_ktls_xmit_wr_complete() returns failure, skb is not freed if it is not the last tls record in this skb, causes refcount never gets freed and tls_dev_del() never gets called on this connection. Fixes: 5a4b9fe7 ("cxgb4/chcr: complete record tx handling") Signed-off-by:
-
Vinay Kumar Yadav authored
commit 1a73e427 upstream. Taking page refcount is not ideal and causes kernel panic sometimes. It's better to take tx_ctx lock for the complete skb transmit, to avoid page cleanup if ACK received in middle. Fixes: 5a4b9fe7 ("cxgb4/chcr: complete record tx handling") Signed-off-by:
-
Lijun Pan authored
commit 7c451f3e upstream. Remove the unnecessary napi_schedule() call in __ibmvnic_open() since interrupt_rx() calls napi_schedule_prep/__napi_schedule during every receive interrupt. Fixes: ed651a10 ("ibmvnic: Updated reset handling") Signed-off-by:
Lijun Pan <lijunp213@gmail.com> Signed-off-by:
-
Lijun Pan authored
commit d3a6abcc upstream. During adapter reset, do_reset/do_hard_reset calls ibmvnic_open(), which will calls napi_schedule if previous state is VNIC_CLOSED (i.e, the reset case, and "ifconfig down" case). So there is no need for do_reset to call napi_schedule again at the end of the function though napi_schedule will neglect the request if napi is already scheduled. Fixes: ed651a10 ("ibmvnic: Updated reset handling") Signed-off-by:
-
Lijun Pan authored
commit 0775ebc4 upstream. __ibmvnic_open calls napi_disable without checking whether NAPI polling has already been disabled or not. This could cause napi_disable being called twice, which could generate deadlock. For example, the first napi_disable will spin until NAPI_STATE_SCHED is cleared by napi_complete_done, then set it again. When napi_disable is called the second time, it will loop infinitely because no dev->poll will be running to clear NAPI_STATE_SCHED. To prevent above scenario from happening, call ibmvnic_napi_disable() which checks if napi is disabled or not before calling napi_disable. Fixes: bfc32f29 ("ibmvnic: Move resource initialization to its own routine") Suggested-by:
Thomas Falcon <tlfalcon@linux.ibm.com> Signed-off-by:
-
John Paul Adrian Glaubitz authored
commit 17786fea upstream. There is no longer an ia64-specific version of the errno.h header below arch/ia64/include/uapi/asm/, so trying to build tools/bpf fails with: CC /usr/src/linux/tools/bpf/bpftool/btf_dumper.o In file included from /usr/src/linux/tools/include/linux/err.h:8, from btf_dumper.c:11: /usr/src/linux/tools/include/uapi/asm/errno.h:13:10: fatal error: ../../../arch/ia64/include/uapi/asm/errno.h: No such file or directory 13 | #include "../../../arch/ia64/include/uapi/asm/errno.h" | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. Thus, just remove the inclusion of the ia64-specific errno.h so that the build will use the generic errno.h header on this target which was used there anyway as the ia64-specific errno.h was just a wrapper for the generic header. Fixes: c25f867d ("ia64: remove unneeded uapi asm-generic wrappers") Signed-off-by:
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by:
-
Randy Dunlap authored
commit 19d000d9 upstream. Fix ia64 generic_defconfig duplicate entries, as warned by: arch/ia64/configs/generic_defconfig: warning: override: reassigning to symbol ATA: => 58 arch/ia64/configs/generic_defconfig: warning: override: reassigning to symbol ATA_PIIX: => 59 These 2 symbols still have the same value as in the removed lines. Link: https://lkml.kernel.org/r/20210411020255.18052-1-rdunlap@infradead.org Fixes: c331649e ("ia64: Use libata instead of the legacy ide driver in defconfigs") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by:
Christoph Hellwig <hch@lst.de> Cc: Tony Luck <tony.luck@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by:
-
Jakub Kicinski authored
commit 16756d3e upstream. The intention was for pause statistics to not be reported when driver does not have the relevant callback (only report an empty netlink nest). What happens currently we report all 0s instead. Make sure statistics are initialized to "not set" (which is -1) so the dumping code skips them. Fixes: 9a27a330 ("ethtool: add standard pause stats") Signed-off-by:
-
Jason Xing authored
commit 4e39a072 upstream. Fix this panic by adding more rules to calculate the value of @rss_size_max which could be used in allocating the queues when bpf is loaded, which, however, could cause the failure and then trigger the NULL pointer of vsi->rx_rings. Prio to this fix, the machine doesn't care about how many cpus are online and then allocates 256 queues on the machine with 32 cpus online actually. Once the load of bpf begins, the log will go like this "failed to get tracking for 256 queues for VSI 0 err -12" and this "setup of MAIN VSI failed". Thus, I attach the key information of the crash-log here. BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: 0010:i40e_xdp+0xdd/0x1b0 [i40e] Call Trace: [2160294.717292] ? i40e_reconfig_rss_queues+0x170/0x170 [i40e] [2160294.717666] dev_xdp_install+0x4f/0x70 [2160294.718036] dev_change_xdp_fd+0x11f/0x230 [2160294.718380] ? dev_disable_lro+0xe0/0xe0 [2160294.718705] do_setlink+0xac7/0xe70 [2160294.719035] ? __nla_parse+0xed/0x120 [2160294.719365] rtnl_newlink+0x73b/0x860 Fixes: 41c445ff ("i40e: main driver core") Co-developed-by:
Shujin Li <lishujin@kuaishou.com> Signed-off-by:
Jason Xing <xingwanli@kuaishou.com> Reviewed-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
-
Lijun Pan authored
commit ca09bf7b upstream. It is more correct to use dev_kfree_skb_irq when packets are dropped, and to use dev_consume_skb_irq when packets are consumed. Fixes: 0d973388 ("ibmvnic: Introduce xmit_more support using batched subCRQ hcalls") Suggested-by:
-
Jonathon Reinhart authored
commit 97684f09 upstream. Currently, tcp_allowed_congestion_control is global and writable; writing to it in any net namespace will leak into all other net namespaces. tcp_available_congestion_control and tcp_allowed_congestion_control are the only sysctls in ipv4_net_table (the per-netns sysctl table) with a NULL data pointer; their handlers (proc_tcp_available_congestion_control and proc_allowed_congestion_control) have no other way of referencing a struct net. Thus, they operate globally. Because ipv4_net_table does not use designated initializers, there is no easy way to fix up this one "bad" table entry. However, the data pointer updating logic shouldn't be applied to NULL pointers anyway, so we instead force these entries to be read-only. These sysctls used to exist in ipv4_table (init-net only), but they were moved to the per-net ipv4_net_table, presumably without realizing that tcp_allowed_congestion_control was writable and thus introduced a leak. Because the intent of that commit was only to know (i.e. read) "which congestion algorithms are available or allowed", this read-only solution should be sufficient. The logic added in recent commit 31c4d2f1: ("net: Ensure net namespace isolation of sysctls") does not and cannot check for NULL data pointers, because other table entries (e.g. /proc/sys/net/netfilter/nf_log/) have .data=NULL but use other methods (.extra2) to access the struct net. Fixes: 9cb8e048 ("net/ipv4/sysctl: show tcp_{allowed, available}_congestion_control in non-initial netns") Signed-off-by:
Jonathon Reinhart <jonathon.reinhart@gmail.com> Signed-off-by:
-
Christophe Leroy authored
commit 45837691 upstream. READ_ONCE() cannot be used for reading PTEs. Use ptep_get() instead, to avoid the following errors: CC mm/ptdump.o In file included from <command-line>: mm/ptdump.c: In function 'ptdump_pte_entry': include/linux/compiler_types.h:320:38: error: call to '__compiletime_assert_207' declared with attribute error: Unsupported access size for {READ,WRITE}_ONCE(). 320 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^ include/linux/compiler_types.h:301:4: note: in definition of macro '__compiletime_assert' 301 | prefix ## suffix(); \ | ^~~~~~ include/linux/compiler_types.h:320:2: note: in expansion of macro '_compiletime_assert' 320 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^~~~~~~~~~~~~~~~~~~ include/asm-generic/rwonce.h:36:2: note: in expansion of macro 'compiletime_assert' 36 | compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \ | ^~~~~~~~~~~~~~~~~~ include/asm-generic/rwonce.h:49:2: note: in expansion of macro 'compiletime_assert_rwonce_type' 49 | compiletime_assert_rwonce_type(x); \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mm/ptdump.c:114:14: note: in expansion of macro 'READ_ONCE' 114 | pte_t val = READ_ONCE(*pte); | ^~~~~~~~~ make[2]: *** [mm/ptdump.o] Error 1 See commit 481e980a ("mm: Allow arches to provide ptep_get()") and commit c0e1c8c2 ("powerpc/8xx: Provide ptep_get() with 16k pages") for details. Link: https://lkml.kernel.org/r/912b349e2bcaa88939904815ca0af945740c6bd4.1618478922.git.christophe.leroy@csgroup.eu Fixes: 30d621f6 ("mm: add generic ptdump") Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Steven Price <steven.price@arm.com> Signed-off-by:
-
Hristo Venev authored
commit 941ea91e upstream. Similarly to the sit case, we need to remove the tunnels with no addresses that have been moved to another network namespace. Fixes: 0bd87628 ("ip6tnl: add x-netns support") Signed-off-by:
Hristo Venev <hristo@venev.name> Signed-off-by:
-
Hristo Venev authored
commit 610f8c0f upstream. A sit interface created without a local or a remote address is linked into the `sit_net::tunnels_wc` list of its original namespace. When deleting a network namespace, delete the devices that have been moved. The following script triggers a null pointer dereference if devices linked in a deleted `sit_net` remain: for i in `seq 1 30`; do ip netns add ns-test ip netns exec ns-test ip link add dev veth0 type veth peer veth1 ip netns exec ns-test ip link add dev sit$i type sit dev veth0 ip netns exec ns-test ip link set dev sit$i netns $$ ip netns del ns-test done for i in `seq 1 30`; do ip link del dev sit$i done Fixes: 5e6700b3 ("sit: add support of x-netns") Signed-off-by:
-
Pali Rohár authored
commit 1fe976d3 upstream. Since commit fee2d546 ("net: phy: marvell: mv88e6390 temperature sensor reading"), Linux reports the temperature of Topaz hwmon as constant -75°C. This is because switches from the Topaz family (88E6141 / 88E6341) have the address of the temperature sensor register different from Peridot. This address is instead compatible with 88E1510 PHYs, as was used for Topaz before the above mentioned commit. Create a new mapping table between switch family and PHY ID for families which don't have a model number. And define PHY IDs for Topaz and Peridot families. Create a new PHY ID and a new PHY driver for Topaz's internal PHY. The only difference from Peridot's PHY driver is the HWMON probing method. Prior this change Topaz's internal PHY is detected by kernel as: PHY [...] driver [Marvell 88E6390] (irq=63) And afterwards as: PHY [...] driver [Marvell 88E6341 Family] (irq=63) Signed-off-by:
Pali Rohár <pali@kernel.org> BugLink: https://github.com/globalscaletechnologies/linux/issues/1 Fixes: fee2d546 ("net: phy: marvell: mv88e6390 temperature sensor reading") Reviewed-by:
Marek Behún <kabel@kernel.org> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Christophe JAILLET authored
commit 31457db3 upstream. When the probe fails, we must disable the regulator that was previously enabled. This patch is a follow-up to commit ac88c531 ("net: davicom: Fix regulator not turned off on failed probe") which missed one case. Fixes: 7994fe55 ("dm9000: Add regulator and reset support to dm9000") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
