aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-05-26hwmon: (amd_energy) Missing platform_driver_unregister() on error in ↵Wei Yongjun1-1/+3
amd_energy_init() Add the missing platform_driver_unregister() before return from amd_energy_init() in the error handling case. Fixes: 8abee9566b7e ("hwmon: Add amd_energy driver to report energy counters") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Wei Yongjun <[email protected]> Acked-by: Naveen krishna Chatradhi <[email protected]> Reported-by: Hulk Robot <[email protected]> Signed-off-by: Wei Yongjun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-05-26net: check untrusted gso_size at kernel entryWillem de Bruijn1-2/+12
Syzkaller again found a path to a kernel crash through bad gso input: a packet with gso size exceeding len. These packets are dropped in tcp_gso_segment and udp[46]_ufo_fragment. But they may affect gso size calculations earlier in the path. Now that we have thlen as of commit 9274124f023b ("net: stricter validation of untrusted gso packets"), check gso_size at entry too. Fixes: bfd5f4a3d605 ("packet: Add GSO/csum offload support.") Reported-by: syzbot <[email protected]> Signed-off-by: Willem de Bruijn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-26mptcp: avoid NULL-ptr derefence on fallbackPaolo Abeni1-1/+2
In the MPTCP receive path we must cope with TCP fallback on blocking recvmsg(). Currently in such code path we detect the fallback condition, but we don't fetch the struct socket required for fallback. The above allowed syzkaller to trigger a NULL pointer dereference: general protection fault, probably for non-canonical address 0xdffffc0000000004: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] CPU: 1 PID: 7226 Comm: syz-executor523 Not tainted 5.7.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:sock_recvmsg_nosec net/socket.c:886 [inline] RIP: 0010:sock_recvmsg+0x92/0x110 net/socket.c:904 Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 44 89 6c 24 04 e8 53 18 1d fb 4d 8d 6f 20 4c 89 e8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 ef e8 20 12 5b fb bd a0 00 00 00 49 03 6d RSP: 0018:ffffc90001077b98 EFLAGS: 00010202 RAX: 0000000000000004 RBX: ffffc90001077dc0 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffffffff86565e59 R09: ffffed10115afeaa R10: ffffed10115afeaa R11: 0000000000000000 R12: 1ffff9200020efbc R13: 0000000000000020 R14: ffffc90001077de0 R15: 0000000000000000 FS: 00007fc6a3abe700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004d0050 CR3: 00000000969f0000 CR4: 00000000001406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mptcp_recvmsg+0x18d5/0x19b0 net/mptcp/protocol.c:891 inet_recvmsg+0xf6/0x1d0 net/ipv4/af_inet.c:838 sock_recvmsg_nosec net/socket.c:886 [inline] sock_recvmsg net/socket.c:904 [inline] __sys_recvfrom+0x2f3/0x470 net/socket.c:2057 __do_sys_recvfrom net/socket.c:2075 [inline] __se_sys_recvfrom net/socket.c:2071 [inline] __x64_sys_recvfrom+0xda/0xf0 net/socket.c:2071 do_syscall_64+0xf3/0x1b0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 Address the issue initializing the struct socket reference before entering the fallback code. Reported-and-tested-by: [email protected] Suggested-by: Ondrej Mosnacek <[email protected]> Fixes: 8ab183deb26a ("mptcp: cope with later TCP fallback") Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-26clk: qcom: gcc: Fix parent for gpll0_out_evenVinod Koul1-2/+1
Documentation says that gpll0 is parent of gpll0_out_even, somehow driver coded that as bi_tcxo, so fix it Fixes: 2a1d7eb854bb ("clk: qcom: gcc: Add global clock controller driver for SM8150") Reported-by: Jonathan Marek <[email protected]> Signed-off-by: Vinod Koul <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2020-05-26clk: qcom: sm8250 gcc depends on QCOM_GDSCJonathan Marek1-0/+1
The driver will always fail to probe without QCOM_GDSC, so select it. Signed-off-by: Jonathan Marek <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Reviewed-by: Bjorn Andersson <[email protected]> Fixes: 3e5770921a88 ("clk: qcom: gcc: Add global clock controller driver for SM8250") Signed-off-by: Stephen Boyd <[email protected]>
2020-05-26net: stmmac: enable timestamp snapshot for required PTP packets in dwmac v5.10aFugang Duan1-1/+2
For rx filter 'HWTSTAMP_FILTER_PTP_V2_EVENT', it should be PTP v2/802.AS1, any layer, any kind of event packet, but HW only take timestamp snapshot for below PTP message: sync, Pdelay_req, Pdelay_resp. Then it causes below issue when test E2E case: ptp4l[2479.534]: port 1: received DELAY_REQ without timestamp ptp4l[2481.423]: port 1: received DELAY_REQ without timestamp ptp4l[2481.758]: port 1: received DELAY_REQ without timestamp ptp4l[2483.524]: port 1: received DELAY_REQ without timestamp ptp4l[2484.233]: port 1: received DELAY_REQ without timestamp ptp4l[2485.750]: port 1: received DELAY_REQ without timestamp ptp4l[2486.888]: port 1: received DELAY_REQ without timestamp ptp4l[2487.265]: port 1: received DELAY_REQ without timestamp ptp4l[2487.316]: port 1: received DELAY_REQ without timestamp Timestamp snapshot dependency on register bits in received path: SNAPTYPSEL TSMSTRENA TSEVNTENA PTP_Messages 01 x 0 SYNC, Follow_Up, Delay_Req, Delay_Resp, Pdelay_Req, Pdelay_Resp, Pdelay_Resp_Follow_Up 01 0 1 SYNC, Pdelay_Req, Pdelay_Resp For dwmac v5.10a, enabling all events by setting register DWC_EQOS_TIME_STAMPING[SNAPTYPSEL] to 2’b01, clearing bit [TSEVNTENA] to 0’b0, which can support all required events. Signed-off-by: Fugang Duan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-26Merge branch 'nexthop-group-fixes'David S. Miller5-79/+205
David Ahern says: ==================== nexthops: Fix 2 fundamental flaws with nexthop groups Nik's torture tests have exposed 2 fundamental mistakes with the initial nexthop code for groups. First, the nexthops entries and num_nh in the nh_grp struct should not be modified once the struct is set under rcu. Doing so has major affects on the datapath seeing valid nexthop entries. Second, the helpers in the header file were convenient for not repeating code, but they cause datapath walks to potentially see 2 different group structs after an rcu replace, disrupting a walk of the path objects. This second problem applies solely to IPv4 as I re-used too much of the existing code in walking legs of a multipath route. Patches 1 is refactoring change to simplify the overhead of reviewing and understanding the change in patch 2 which fixes the update of nexthop groups when a compnent leg is removed. Patches 3-5 address the second problem. Patch 3 inlines the multipath check such that the mpath lookup and subsequent calls all use the same nh_grp struct. Patches 4 and 5 fix datapath uses of fib_info_num_path with iterative calls to fib_info_nhc. fib_info_num_path can be used in control plane path in a 'for loop' with subsequent fib_info_nhc calls to get each leg since the nh_grp struct is only changed while holding the rtnl; the combination can not be used in the data plane with external nexthops as it involves repeated dereferences of nh_grp struct which can change between calls. Similarly, nexthop_is_multipath can be used for branching decisions in the datapath since the nexthop type can not be changed (a group can not be converted to standalone and vice versa). Patch set developed in coordination with Nikolay Aleksandrov. He did a lot of work creating a good reproducer, discussing options to fix it and testing iterations. I have adapted Nik's commands into additional tests in the nexthops selftest script which I will send against -next. v2 - fixed whitespace errors ==================== Signed-off-by: David S. Miller <[email protected]>
2020-05-26ipv4: nexthop version of fib_info_nh_uses_devDavid Ahern3-9/+45
Similar to the last path, need to fix fib_info_nh_uses_dev for external nexthops to avoid referencing multiple nh_grp structs. Move the device check in fib_info_nh_uses_dev to a helper and create a nexthop version that is called if the fib_info uses an external nexthop. Fixes: 430a049190de ("nexthop: Add support for nexthop groups") Signed-off-by: David Ahern <[email protected]> Acked-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-26ipv4: Refactor nhc evaluation in fib_table_lookupDavid Ahern3-15/+71
FIB lookups can return an entry that references an external nexthop. While walking the nexthop struct we do not want to make multiple calls into the nexthop code which can result in 2 different structs getting accessed - one returning the number of paths the rest of the loop seeing a different nh_grp struct. If the nexthop group shrunk, the result is an attempt to access a fib_nh_common that does not exist for the new nh_grp struct but did for the old one. To fix that move the device evaluation code to a helper that can be used for inline fib_nh path as well as external nexthops. Update the existing check for fi->nh in fib_table_lookup to call a new helper, nexthop_get_nhc_lookup, which walks the external nexthop with a single rcu dereference. Fixes: 430a049190de ("nexthop: Add support for nexthop groups") Signed-off-by: David Ahern <[email protected]> Acked-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-26nexthop: Expand nexthop_is_multipath in a few placesDavid Ahern1-16/+25
I got too fancy consolidating checks on multipath type. The result is that path lookups can access 2 different nh_grp structs as exposed by Nik's torture tests. Expand nexthop_is_multipath within nexthop.h to avoid multiple, nh_grp dereferences and make decisions based on the consistent struct. Only 2 places left using nexthop_is_multipath are within IPv6, both only check that the nexthop is a multipath for a branching decision which are acceptable. Fixes: 430a049190de ("nexthop: Add support for nexthop groups") Signed-off-by: David Ahern <[email protected]> Acked-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-26nexthops: don't modify published nexthop groupsNikolay Aleksandrov2-33/+59
We must avoid modifying published nexthop groups while they might be in use, otherwise we might see NULL ptr dereferences. In order to do that we allocate 2 nexthoup group structures upon nexthop creation and swap between them when we have to delete an entry. The reason is that we can't fail nexthop group removal, so we can't handle allocation failure thus we move the extra allocation on creation where we can safely fail and return ENOMEM. Fixes: 430a049190de ("nexthop: Add support for nexthop groups") Signed-off-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-26nexthops: Move code from remove_nexthop_from_groups to remove_nh_grp_entryDavid Ahern1-14/+13
Move nh_grp dereference and check for removing nexthop group due to all members gone into remove_nh_grp_entry. Fixes: 430a049190de ("nexthop: Add support for nexthop groups") Signed-off-by: David Ahern <[email protected]> Acked-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-26exec: Always set cap_ambient in cap_bprm_set_credsEric W. Biederman1-0/+1
An invariant of cap_bprm_set_creds is that every field in the new cred structure that cap_bprm_set_creds might set, needs to be set every time to ensure the fields does not get a stale value. The field cap_ambient is not set every time cap_bprm_set_creds is called, which means that if there is a suid or sgid script with an interpreter that has neither the suid nor the sgid bits set the interpreter should be able to accept ambient credentials. Unfortuantely because cap_ambient is not reset to it's original value the interpreter can not accept ambient credentials. Given that the ambient capability set is expected to be controlled by the caller, I don't think this is particularly serious. But it is definitely worth fixing so the code works correctly. I have tested to verify my reading of the code is correct and the interpreter of a sgid can receive ambient capabilities with this change and cannot receive ambient capabilities without this change. Cc: [email protected] Cc: Andy Lutomirski <[email protected]> Fixes: 58319057b784 ("capabilities: ambient capabilities") Signed-off-by: "Eric W. Biederman" <[email protected]>
2020-05-26spi: spi-fsl-lpspi: Fix runtime PM imbalance on errorDinghao Liu1-2/+4
pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-05-26spi: Remove note about transfer limit for spi_write_then_read()Mark Brown1-2/+1
Originally spi_write_then_read() used a fixed statically allocated buffer which limited the maximum message size it could handle. This restriction was removed a while ago so that we could dynamically allocate a buffer if required but the kerneldoc was not updated to reflect this, do so. Reported-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-05-26sched/fair: Don't NUMA balance for kthreadsJens Axboe1-1/+1
Stefano reported a crash with using SQPOLL with io_uring: BUG: kernel NULL pointer dereference, address: 00000000000003b0 CPU: 2 PID: 1307 Comm: io_uring-sq Not tainted 5.7.0-rc7 #11 RIP: 0010:task_numa_work+0x4f/0x2c0 Call Trace: task_work_run+0x68/0xa0 io_sq_thread+0x252/0x3d0 kthread+0xf9/0x130 ret_from_fork+0x35/0x40 which is task_numa_work() oopsing on current->mm being NULL. The task work is queued by task_tick_numa(), which checks if current->mm is NULL at the time of the call. But this state isn't necessarily persistent, if the kthread is using use_mm() to temporarily adopt the mm of a task. Change the task_tick_numa() check to exclude kernel threads in general, as it doesn't make sense to attempt ot balance for kthreads anyway. Reported-by: Stefano Garzarella <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-05-26x86/syscalls: Revert "x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long"Andy Lutomirski2-3/+10
Revert 45e29d119e99 ("x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long") and add a comment to discourage someone else from making the same mistake again. It turns out that some user code fails to compile if __X32_SYSCALL_BIT is unsigned long. See, for example [1] below. [ bp: Massage and do the same thing in the respective tools/ header. ] Fixes: 45e29d119e99 ("x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long") Reported-by: Thorsten Glaser <[email protected]> Signed-off-by: Andy Lutomirski <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Cc: [email protected] Link: [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954294 Link: https://lkml.kernel.org/r/92e55442b744a5951fdc9cfee10badd0a5f7f828.1588983892.git.luto@kernel.org
2020-05-26spi: pxa2xx: Fix runtime PM ref imbalance on probe errorLukas Wunner1-1/+0
The PXA2xx SPI driver releases a runtime PM ref in the probe error path even though it hasn't acquired a ref earlier. Apparently commit e2b714afee32 ("spi: pxa2xx: Disable runtime PM if controller registration fails") sought to copy-paste the invocation of pm_runtime_disable() from pxa2xx_spi_remove(), but erroneously copied the call to pm_runtime_put_noidle() as well. Drop it. Fixes: e2b714afee32 ("spi: pxa2xx: Disable runtime PM if controller registration fails") Signed-off-by: Lukas Wunner <[email protected]> Reviewed-by: Jarkko Nikula <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: [email protected] # v4.17+ Cc: Jarkko Nikula <[email protected]> Link: https://lore.kernel.org/r/58b2ac6942ca1f91aaeeafe512144bc5343e1d84.1590408496.git.lukas@wunner.de Signed-off-by: Mark Brown <[email protected]>
2020-05-26spi: pxa2xx: Fix controller unregister orderLukas Wunner1-1/+3
The PXA2xx SPI driver uses devm_spi_register_controller() on bind. As a consequence, on unbind, __device_release_driver() first invokes pxa2xx_spi_remove() before unregistering the SPI controller via devres_release_all(). This order is incorrect: pxa2xx_spi_remove() disables the chip, rendering the SPI bus inaccessible even though the SPI controller is still registered. When the SPI controller is subsequently unregistered, it unbinds all its slave devices. Because their drivers cannot access the SPI bus, e.g. to quiesce interrupts, the slave devices may be left in an improper state. As a rule, devm_spi_register_controller() must not be used if the ->remove() hook performs teardown steps which shall be performed after unregistering the controller and specifically after unbinding of slaves. Fix by reverting to the non-devm variant of spi_register_controller(). An alternative approach would be to use device-managed functions for all steps in pxa2xx_spi_remove(), e.g. by calling devm_add_action_or_reset() on probe. However that approach would add more LoC to the driver and it wouldn't lend itself as well to backporting to stable. The improper use of devm_spi_register_controller() was introduced in 2013 by commit a807fcd090d6 ("spi: pxa2xx: use devm_spi_register_master()"), but all earlier versions of the driver going back to 2006 were likewise broken because they invoked spi_unregister_master() at the end of pxa2xx_spi_remove(), rather than at the beginning. Fixes: e0c9905e87ac ("[PATCH] SPI: add PXA2xx SSP SPI Driver") Signed-off-by: Lukas Wunner <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: [email protected] # v2.6.17+ Cc: Tsuchiya Yuto <[email protected]> Link: https://bugzilla.kernel.org/show_bug.cgi?id=206403#c1 Link: https://lore.kernel.org/r/834c446b1cf3284d2660f1bee1ebe3e737cd02a9.1590408496.git.lukas@wunner.de Signed-off-by: Mark Brown <[email protected]>
2020-05-26spi: dw: Fix controller unregister orderLukas Wunner1-1/+3
The Designware SPI driver uses devm_spi_register_controller() on bind. As a consequence, on unbind, __device_release_driver() first invokes dw_spi_remove_host() before unregistering the SPI controller via devres_release_all(). This order is incorrect: dw_spi_remove_host() shuts down the chip, rendering the SPI bus inaccessible even though the SPI controller is still registered. When the SPI controller is subsequently unregistered, it unbinds all its slave devices. Because their drivers cannot access the SPI bus, e.g. to quiesce interrupts, the slave devices may be left in an improper state. As a rule, devm_spi_register_controller() must not be used if the ->remove() hook performs teardown steps which shall be performed after unregistering the controller and specifically after unbinding of slaves. Fix by reverting to the non-devm variant of spi_register_controller(). An alternative approach would be to use device-managed functions for all steps in dw_spi_remove_host(), e.g. by calling devm_add_action_or_reset() on probe. However that approach would add more LoC to the driver and it wouldn't lend itself as well to backporting to stable. Fixes: 04f421e7b0b1 ("spi: dw: use managed resources") Signed-off-by: Lukas Wunner <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: [email protected] # v3.14+ Cc: Baruch Siach <[email protected]> Link: https://lore.kernel.org/r/3fff8cb8ae44a9893840d0688be15bb88c090a14.1590408496.git.lukas@wunner.de Signed-off-by: Mark Brown <[email protected]>
2020-05-26powerpc/64s: Fix restore of NV GPRs after facility unavailable exceptionMichael Ellerman1-0/+2
Commit 702f09805222 ("powerpc/64s/exception: Remove lite interrupt return") changed the interrupt return path to not restore non-volatile registers by default, and explicitly restore them in paths where it is required. But it missed that the facility unavailable exception can sometimes modify user registers, ie. when it does emulation of move from DSCR. This is seen as a failure of the dscr_sysfs_thread_test: test: dscr_sysfs_thread_test [cpu 0] User DSCR should be 1 but is 0 failure: dscr_sysfs_thread_test So restore non-volatile GPRs after facility unavailable exceptions. Currently the hypervisor facility unavailable exception is also wired up to call facility_unavailable_exception(). In practice we should never take a hypervisor facility unavailable exception for the DSCR. On older bare metal systems we set HFSCR_DSCR unconditionally in __init_HFSCR, or on newer systems it should be enabled via the "data-stream-control-register" device tree CPU feature. Even if it's not, since commit f3c99f97a3cd ("KVM: PPC: Book3S HV: Don't access HFSCR, LPIDR or LPCR when running nested"), the KVM code has unconditionally set HFSCR_DSCR when running guests. So we should only get a hypervisor facility unavailable for the DSCR if skiboot has disabled the "data-stream-control-register" feature, and we are somehow in guest context but not via KVM. Given all that, it should be unnecessary to add a restore of non-volatile GPRs after the hypervisor facility exception, because we never expect to hit that path. But equally we may as well add the restore, because we never expect to hit that path, and if we ever did, at least we would correctly restore the registers to their post emulation state. In future we can split the non-HV and HV facility unavailable handling so that there is no emulation in the HV handler, and then remove the restore for the HV case. Fixes: 702f09805222 ("powerpc/64s/exception: Remove lite interrupt return") Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-05-26ALSA: usb-audio: mixer: volume quirk for ESS Technology Asus USB DACChris Chiu1-0/+8
The Asus USB DAC is a USB type-C audio dongle for connecting to the headset and headphone. The volume minimum value -23040 which is 0xa600 in hexadecimal with the resolution value 1 indicates this should be endianness issue caused by the firmware bug. Add a volume quirk to fix the volume control problem. Also fixes this warning: Warning! Unlikely big volume range (=23040), cval->res is probably wrong. [5] FU [Headset Capture Volume] ch = 1, val = -23040/0/1 Warning! Unlikely big volume range (=23040), cval->res is probably wrong. [7] FU [Headset Playback Volume] ch = 1, val = -23040/0/1 Signed-off-by: Chris Chiu <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-05-26ALSA: hda/realtek - Add a model for Thinkpad T570 without DAC workaroundTakashi Iwai1-10/+26
We fixed the regression of the speaker volume for some Thinkpad models (e.g. T570) by the commit 54947cd64c1b ("ALSA: hda/realtek - Fix speaker output regression on Thinkpad T570"). Essentially it fixes the DAC / pin pairing by a static table. It was confirmed and merged to stable kernel later. Now, interestingly, we got another regression report for the very same model (T570) about the similar problem, and the commit above was the culprit. That is, by some reason, there are devices that prefer the DAC1, and another device DAC2! Unfortunately those have the same ID and we have no idea what can differentiate, in this patch, a new fixup model "tpt470-dock-fix" is provided, so that users with such a machine can apply it manually. When model=tpt470-dock-fix option is passed to snd-hda-intel module, it avoids the fixed DAC pairing and the DAC1 is assigned to the speaker like the earlier versions. Fixes: 54947cd64c1b ("ALSA: hda/realtek - Fix speaker output regression on Thinkpad T570") BugLink: https://apibugzilla.suse.com/show_bug.cgi?id=1172017 Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-05-26ALSA: hwdep: fix a left shifting 1 by 31 UB bugChangming Liu1-2/+2
The "info.index" variable can be 31 in "1 << info.index". This might trigger an undefined behavior since 1 is signed. Fix this by casting 1 to 1u just to be sure "1u << 31" is defined. Signed-off-by: Changming Liu <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/BL0PR06MB4548170B842CB055C9AF695DE5B00@BL0PR06MB4548.namprd06.prod.outlook.com Signed-off-by: Takashi Iwai <[email protected]>
2020-05-25Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller7-41/+119
Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains Netfilter fixes for net: 1) Set VLAN tag in tcp reset/icmp unreachable packets to reject connections in the bridge family, from Michael Braun. 2) Incorrect subcounter flag update in ipset, from Phil Sutter. 3) Possible buffer overflow in the pptp conntrack helper, based on patch from Dan Carpenter. 4) Restore userspace conntrack helper hook logic that broke after hook consolidation rework. 5) Unbreak userspace conntrack helper registration via nfnetlink_cthelper. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-05-25Merge tag 'mac80211-for-net-2020-05-25' of ↵David S. Miller3-2/+9
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 Johannes Berg says: ==================== A few changes: * fix a debugfs vs. wiphy rename crash * fix an invalid HE spec definition * fix a mesh timer crash ==================== Signed-off-by: David S. Miller <[email protected]>
2020-05-25qlcnic: fix missing release in qlcnic_83xx_interrupt_test.Qiushi Wu1-1/+3
In function qlcnic_83xx_interrupt_test(), function qlcnic_83xx_diag_alloc_res() is not handled by function qlcnic_83xx_diag_free_res() after a call of the function qlcnic_alloc_mbx_args() failed. Fix this issue by adding a jump target "fail_mbx_args", and jump to this new target when qlcnic_alloc_mbx_args() failed. Fixes: b6b4316c8b2f ("qlcnic: Handle qlcnic_alloc_mbx_args() failure") Signed-off-by: Qiushi Wu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-25dpaa_eth: fix usage as DSA master, try 3Vladimir Oltean1-1/+1
The dpaa-eth driver probes on compatible string for the MAC node, and the fman/mac.c driver allocates a dpaa-ethernet platform device that triggers the probing of the dpaa-eth net device driver. All of this is fine, but the problem is that the struct device of the dpaa_eth net_device is 2 parents away from the MAC which can be referenced via of_node. So of_find_net_device_by_node can't find it, and DSA switches won't be able to probe on top of FMan ports. It would be a bit silly to modify a core function (of_find_net_device_by_node) to look for dev->parent->parent->of_node just for one driver. We're just 1 step away from implementing full recursion. Actually there have already been at least 2 previous attempts to make this work: - Commit a1a50c8e4c24 ("fsl/man: Inherit parent device and of_node") - One or more of the patches in "[v3,0/6] adapt DPAA drivers for DSA": https://patchwork.ozlabs.org/project/netdev/cover/[email protected]/ (I couldn't really figure out which one was supposed to solve the problem and how). Point being, it looks like this is still pretty much a problem today. On T1040, the /sys/class/net/eth0 symlink currently points to ../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/dpaa-ethernet.0/net/eth0 which pretty much illustrates the problem. The closest of_node we've got is the "fsl,fman-memac" at /soc@ffe000000/fman@400000/ethernet@e6000, which is what we'd like to be able to reference from DSA as host port. For of_find_net_device_by_node to find the eth0 port, we would need the parent of the eth0 net_device to not be the "dpaa-ethernet" platform device, but to point 1 level higher, aka the "fsl,fman-memac" node directly. The new sysfs path would look like this: ../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/net/eth0 And this is exactly what SET_NETDEV_DEV does. It sets the parent of the net_device. The new parent has an of_node associated with it, and of_dev_node_match already checks for the of_node of the device or of its parent. Fixes: a1a50c8e4c24 ("fsl/man: Inherit parent device and of_node") Fixes: c6e26ea8c893 ("dpaa_eth: change device used") Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-25net/tls: fix race condition causing kernel panicVinay Kumar Yadav2-6/+31
tls_sw_recvmsg() and tls_decrypt_done() can be run concurrently. // tls_sw_recvmsg() if (atomic_read(&ctx->decrypt_pending)) crypto_wait_req(-EINPROGRESS, &ctx->async_wait); else reinit_completion(&ctx->async_wait.completion); //tls_decrypt_done() pending = atomic_dec_return(&ctx->decrypt_pending); if (!pending && READ_ONCE(ctx->async_notify)) complete(&ctx->async_wait.completion); Consider the scenario tls_decrypt_done() is about to run complete() if (!pending && READ_ONCE(ctx->async_notify)) and tls_sw_recvmsg() reads decrypt_pending == 0, does reinit_completion(), then tls_decrypt_done() runs complete(). This sequence of execution results in wrong completion. Consequently, for next decrypt request, it will not wait for completion, eventually on connection close, crypto resources freed, there is no way to handle pending decrypt response. This race condition can be avoided by having atomic_read() mutually exclusive with atomic_dec_return(),complete().Intoduced spin lock to ensure the mutual exclution. Addressed similar problem in tx direction. v1->v2: - More readable commit message. - Corrected the lock to fix new race scenario. - Removed barrier which is not needed now. Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption of records for performance") Signed-off-by: Vinay Kumar Yadav <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-25Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-armLinus Torvalds7-93/+127
Pull ARM fixes from Russell King: - correct value of decompressor tag size in header - fix DACR value when we have nested exceptions - fix a missing newline on a kernel message - fix mask for ptrace thumb breakpoint hook * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: 8977/1: ptrace: Fix mask for thumb breakpoint hook ARM: 8973/1: Add missing newline terminator to kernel message ARM: uaccess: fix DACR mismatch with nested exceptions ARM: uaccess: integrate uaccess_save and uaccess_restore ARM: uaccess: consolidate uaccess asm to asm/uaccess-asm.h ARM: 8970/1: decompressor: increase tag size
2020-05-26Merge tag 'omap-for-v5.7/cpsw-fixes-signed' of ↵Arnd Bergmann7-11/+11
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes Few cpsw related dts fixes for omaps Recent cpsw driver changes exposed few regressions in the cpsw related dts configuration that would be good to fix: - Few more boards still need to be updated to use rgmii-rxid phy caused by the fallout from commit bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY" as the rx delay is now disabled unless we use rgmii-rxid. - On dm814x we have been using a wrong clock for mdio that now can produce external abort on some boards * tag 'omap-for-v5.7/cpsw-fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: dts: Fix wrong mdio clock for dm814x ARM: dts: am437x: fix networking on boards with ksz9031 phy ARM: dts: am57xx: fix networking on boards with ksz9031 phy Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2020-05-26xsk: Add overflow check for u64 division, stored into u32Björn Töpel1-2/+6
The npgs member of struct xdp_umem is an u32 entity, and stores the number of pages the UMEM consumes. The calculation of npgs npgs = size / PAGE_SIZE can overflow. To avoid overflow scenarios, the division is now first stored in a u64, and the result is verified to fit into 32b. An alternative would be storing the npgs as a u64, however, this wastes memory and is an unrealisticly large packet area. Fixes: c0c77d8fb787 ("xsk: add user memory registration support sockopt") Reported-by: "Minh Bùi Quang" <[email protected]> Signed-off-by: Björn Töpel <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Jonathan Lemon <[email protected]> Link: https://lore.kernel.org/bpf/CACtPs=GGvV-_Yj6rbpzTVnopgi5nhMoCcTkSkYrJHGQHJWFZMQ@mail.gmail.com/ Link: https://lore.kernel.org/bpf/[email protected]
2020-05-25netfilter: nfnetlink_cthelper: unbreak userspace helper supportPablo Neira Ayuso1-1/+2
Restore helper data size initialization and fix memcopy of the helper data size. Fixes: 157ffffeb5dc ("netfilter: nfnetlink_cthelper: reject too large userspace allocation requests") Reviewed-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2020-05-25netfilter: conntrack: make conntrack userspace helpers work againPablo Neira Ayuso1-6/+72
Florian Westphal says: "Problem is that after the helper hook was merged back into the confirm one, the queueing itself occurs from the confirm hook, i.e. we queue from the last netfilter callback in the hook-list. Therefore, on return, the packet bypasses the confirm action and the connection is never committed to the main conntrack table. To fix this there are several ways: 1. revert the 'Fixes' commit and have a extra helper hook again. Works, but has the drawback of adding another indirect call for everyone. 2. Special case this: split the hooks only when userspace helper gets added, so queueing occurs at a lower priority again, and normal enqueue reinject would eventually call the last hook. 3. Extend the existing nf_queue ct update hook to allow a forced confirmation (plus run the seqadj code). This goes for 3)." Fixes: 827318feb69cb ("netfilter: conntrack: remove helper hook again") Reviewed-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2020-05-25netfilter: nf_conntrack_pptp: prevent buffer overflows in debug codePablo Neira Ayuso3-33/+38
Dan Carpenter says: "Smatch complains that the value for "cmd" comes from the network and can't be trusted." Add pptp_msg_name() helper function that checks for the array boundary. Fixes: f09943fefe6b ("[NETFILTER]: nf_conntrack/nf_nat: add PPTP helper port") Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2020-05-25netfilter: ipset: Fix subcounter update skipPhil Sutter1-1/+1
If IPSET_FLAG_SKIP_SUBCOUNTER_UPDATE is set, user requested to not update counters in sub sets. Therefore IPSET_FLAG_SKIP_COUNTER_UPDATE must be set, not unset. Fixes: 6e01781d1c80e ("netfilter: ipset: set match: add support to match the counters") Signed-off-by: Phil Sutter <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2020-05-25netfilter: nft_reject_bridge: enable reject with bridge vlanMichael Braun1-0/+6
Currently, using the bridge reject target with tagged packets results in untagged packets being sent back. Fix this by mirroring the vlan id as well. Fixes: 85f5b3086a04 ("netfilter: bridge: add reject support") Signed-off-by: Michael Braun <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2020-05-25RDMA/pvrdma: Fix missing pci disable in pvrdma_pci_probe()Qiushi Wu1-1/+1
In function pvrdma_pci_probe(), pdev was not disabled in one error path. Thus replace the jump target “err_free_device” by "err_disable_pdev". Fixes: 29c8d9eba550 ("IB: Add vmw_pvrdma driver") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Qiushi Wu <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-05-25spi: flags 'SPI_CONTROLLER_MUST_RX' and 'SPI_CONTROLLER_MUST_TX' can't be ↵dillon min1-1/+2
coexit with 'SPI_3WIRE' mode since chip spi driver need get the transfer direction by 'tx_buf' and 'rx_buf' of 'struct spi_transfer' in 'SPI_3WIRE' mode. so, we need bypass 'SPI_CONTROLLER_MUST_RX' and 'SPI_CONTROLLER_MUST_TX' feature in 'SPI_3WIRE' mode Signed-off-by: dillon min <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-05-25spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4dillon min1-4/+15
in l3gd20 driver startup, there is a setup failed error return from stm32 spi driver " [ 2.687630] st-gyro-spi spi0.0: supply vdd not found, using dummy regulator [ 2.696869] st-gyro-spi spi0.0: supply vddio not found, using dummy regulator [ 2.706707] spi_stm32 40015000.spi: SPI transfer setup failed [ 2.713741] st-gyro-spi spi0.0: SPI transfer failed: -22 [ 2.721096] spi_master spi0: failed to transfer one message from queue [ 2.729268] iio iio:device0: failed to read Who-Am-I register. [ 2.737504] st-gyro-spi: probe of spi0.0 failed with error -22 " after debug into spi-stm32 driver, st-gyro-spi split two steps to read l3gd20 id first: send command to l3gd20 with read id command in tx_buf, rx_buf is null. second: read id with tx_buf is null, rx_buf not null. so, for second step, stm32 driver recongise this process as 'SPI_SIMPLE_RX' from stm32_spi_communication_type(), but there is no related process for this type in stm32f4_spi_set_mode(), then we get error from stm32_spi_transfer_one_setup(). we can use two method to fix this bug. 1, use stm32 spi's "In unidirectional receive-only mode (BIDIMODE=0 and RXONLY=1)". but as our code running in sdram, the read latency is too large to get so many receive overrun error in interrupts handler. 2, use stm32 spi's "In full-duplex (BIDIMODE=0 and RXONLY=0)", as tx_buf is null, so add flag 'SPI_MASTER_MUST_TX' to spi master. Change since V4: 1 remove dummy data sent out by stm32 spi driver 2 add flag 'SPI_MASTER_MUST_TX' to spi master Signed-off-by: dillon min <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-05-25xfrm: fix a warning in xfrm_policy_insert_listXin Long1-6/+1
This waring can be triggered simply by: # ip xfrm policy update src 192.168.1.1/24 dst 192.168.1.2/24 dir in \ priority 1 mark 0 mask 0x10 #[1] # ip xfrm policy update src 192.168.1.1/24 dst 192.168.1.2/24 dir in \ priority 2 mark 0 mask 0x1 #[2] # ip xfrm policy update src 192.168.1.1/24 dst 192.168.1.2/24 dir in \ priority 2 mark 0 mask 0x10 #[3] Then dmesg shows: [ ] WARNING: CPU: 1 PID: 7265 at net/xfrm/xfrm_policy.c:1548 [ ] RIP: 0010:xfrm_policy_insert_list+0x2f2/0x1030 [ ] Call Trace: [ ] xfrm_policy_inexact_insert+0x85/0xe50 [ ] xfrm_policy_insert+0x4ba/0x680 [ ] xfrm_add_policy+0x246/0x4d0 [ ] xfrm_user_rcv_msg+0x331/0x5c0 [ ] netlink_rcv_skb+0x121/0x350 [ ] xfrm_netlink_rcv+0x66/0x80 [ ] netlink_unicast+0x439/0x630 [ ] netlink_sendmsg+0x714/0xbf0 [ ] sock_sendmsg+0xe2/0x110 The issue was introduced by Commit 7cb8a93968e3 ("xfrm: Allow inserting policies with matching mark and different priorities"). After that, the policies [1] and [2] would be able to be added with different priorities. However, policy [3] will actually match both [1] and [2]. Policy [1] was matched due to the 1st 'return true' in xfrm_policy_mark_match(), and policy [2] was matched due to the 2nd 'return true' in there. It caused WARN_ON() in xfrm_policy_insert_list(). This patch is to fix it by only (the same value and priority) as the same policy in xfrm_policy_mark_match(). Thanks to Yuehaibing, we could make this fix better. v1->v2: - check policy->mark.v == pol->mark.v only without mask. Fixes: 7cb8a93968e3 ("xfrm: Allow inserting policies with matching mark and different priorities") Reported-by: Xiumei Mu <[email protected]> Signed-off-by: Xin Long <[email protected]> Signed-off-by: Steffen Klassert <[email protected]>
2020-05-25spi: mux: repair mux usagePeter Rosin1-4/+4
It is not valid to cache/short out selection of the mux. mux_control_select() only locks the mux until mux_control_deselect() is called. mux_control_deselect() may put the mux in some low power state or some other user of the mux might select it for other purposes. These things are probably not happening in the original setting where this driver was developed, but it is said to be a generic SPI mux. Also, the mux framework will short out the actual low level muxing operation when/if that is possible. Fixes: e9e40543ad5b ("spi: Add generic SPI multiplexer") Signed-off-by: Peter Rosin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-05-25cfg80211: fix debugfs rename crashJohannes Berg1-1/+1
Removing the "if (IS_ERR(dir)) dir = NULL;" check only works if we adjust the remaining code to not rely on it being NULL. Check IS_ERR_OR_NULL() before attempting to dereference it. I'm not actually entirely sure this fixes the syzbot crash as the kernel config indicates that they do have DEBUG_FS in the kernel, but this is what I found when looking there. Cc: [email protected] Fixes: d82574a8e5a4 ("cfg80211: no need to check return value of debugfs_create functions") Reported-by: [email protected] Reviewed-by: Greg Kroah-Hartman <[email protected]> Link: https://lore.kernel.org/r/20200525113816.fc4da3ec3d4b.Ica63a110679819eaa9fb3bc1b7437d96b1fd187d@changeid Signed-off-by: Johannes Berg <[email protected]>
2020-05-25Merge tag 'arm-soc/for-5.7/devicetree-fixes-part2-v2' of ↵Arnd Bergmann2-4/+4
https://github.com/Broadcom/stblinux into arm/fixes This pull request contains Broadcom ARM-based SoCs Device Tree fixes for 5.7, please pull the following: - Vincent fixes the polarity of the ACT LED on the Raspberry Pi Zero W board - Hamish fixes the ARM PPI interrupts sensitivy for the Hurricane 2 SoCs * tag 'arm-soc/for-5.7/devicetree-fixes-part2-v2' of https://github.com/Broadcom/stblinux: ARM: dts: bcm: HR2: Fix PPI interrupt types ARM: dts: bcm2835-rpi-zero-w: Fix led polarity Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2020-05-25gpio: bcm-kona: Fix return value of bcm_kona_gpio_probe()Tiezhu Yang1-1/+1
Propagate the error code returned by devm_platform_ioremap_resource() out of probe() instead of overwriting it. Fixes: 72d8cb715477 ("drivers: gpio: bcm-kona: use devm_platform_ioremap_resource()") Signed-off-by: Tiezhu Yang <[email protected]> [Bartosz: tweaked the commit message] Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-05-25gpio: pxa: Fix return value of pxa_gpio_probe()Tiezhu Yang1-2/+2
When call function devm_platform_ioremap_resource(), we should use IS_ERR() to check the return value and return PTR_ERR() if failed. Fixes: 542c25b7a209 ("drivers: gpio: pxa: use devm_platform_ioremap_resource()") Signed-off-by: Tiezhu Yang <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-05-25gpio: mlxbf2: Fix sleeping while holding spinlockAxel Lin1-3/+3
mutex_lock() can sleep, don't call mutex_lock() while holding spin_lock. Fixes: bc0ae0e737f5 ("gpio: add driver for Mellanox BlueField 2 GPIO controller") Signed-off-by: Axel Lin <[email protected]> Acked-by: [email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-05-25mmc: block: Fix use-after-free issue for rpmbPeng Hao1-1/+1
The data structure member “rpmb->md” was passed to a call of the function “mmc_blk_put” after a call of the function “put_device”. Reorder these function calls to keep the data accesses consistent. Fixes: 1c87f7357849 ("mmc: block: Fix bug when removing RPMB chardev ") Signed-off-by: Peng Hao <[email protected]> Cc: [email protected] [Uffe: Fixed up mangled patch and updated commit message] Signed-off-by: Ulf Hansson <[email protected]>
2020-05-25ieee80211: Fix incorrect mask for default PE durationPradeep Kumar Chitrapu1-1/+1
Fixes bitmask for HE opration's default PE duration. Fixes: daa5b83513a7 ("mac80211: update HE operation fields to D3.0") Signed-off-by: Pradeep Kumar Chitrapu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2020-05-25mac80211: mesh: fix discovery timer re-arming issue / crashLinus Lüssing1-0/+7
On a non-forwarding 802.11s link between two fairly busy neighboring nodes (iperf with -P 16 at ~850MBit/s TCP; 1733.3 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 4), so with frequent PREQ retries, usually after around 30-40 seconds the following crash would occur: [ 1110.822428] Unable to handle kernel read from unreadable memory at virtual address 00000000 [ 1110.830786] Mem abort info: [ 1110.833573] Exception class = IABT (current EL), IL = 32 bits [ 1110.839494] SET = 0, FnV = 0 [ 1110.842546] EA = 0, S1PTW = 0 [ 1110.845678] user pgtable: 4k pages, 48-bit VAs, pgd = ffff800076386000 [ 1110.852204] [0000000000000000] *pgd=00000000f6322003, *pud=00000000f62de003, *pmd=0000000000000000 [ 1110.861167] Internal error: Oops: 86000004 [#1] PREEMPT SMP [ 1110.866730] Modules linked in: pppoe ppp_async batman_adv ath10k_pci ath10k_core ath pppox ppp_generic nf_conntrack_ipv6 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_mangle iptable_filter ip_tables crc_ccitt compat nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 usb_storage xhci_plat_hcd xhci_pci xhci_hcd dwc3 usbcore usb_common [ 1110.932190] Process swapper/3 (pid: 0, stack limit = 0xffff0000090c8000) [ 1110.938884] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.14.162 #0 [ 1110.944965] Hardware name: LS1043A RGW Board (DT) [ 1110.949658] task: ffff8000787a81c0 task.stack: ffff0000090c8000 [ 1110.955568] PC is at 0x0 [ 1110.958097] LR is at call_timer_fn.isra.27+0x24/0x78 [ 1110.963055] pc : [<0000000000000000>] lr : [<ffff0000080ff29c>] pstate: 00400145 [ 1110.970440] sp : ffff00000801be10 [ 1110.973744] x29: ffff00000801be10 x28: ffff000008bf7018 [ 1110.979047] x27: ffff000008bf87c8 x26: ffff000008c160c0 [ 1110.984352] x25: 0000000000000000 x24: 0000000000000000 [ 1110.989657] x23: dead000000000200 x22: 0000000000000000 [ 1110.994959] x21: 0000000000000000 x20: 0000000000000101 [ 1111.000262] x19: ffff8000787a81c0 x18: 0000000000000000 [ 1111.005565] x17: ffff0000089167b0 x16: 0000000000000058 [ 1111.010868] x15: ffff0000089167b0 x14: 0000000000000000 [ 1111.016172] x13: ffff000008916788 x12: 0000000000000040 [ 1111.021475] x11: ffff80007fda9af0 x10: 0000000000000001 [ 1111.026777] x9 : ffff00000801bea0 x8 : 0000000000000004 [ 1111.032080] x7 : 0000000000000000 x6 : ffff80007fda9aa8 [ 1111.037383] x5 : ffff00000801bea0 x4 : 0000000000000010 [ 1111.042685] x3 : ffff00000801be98 x2 : 0000000000000614 [ 1111.047988] x1 : 0000000000000000 x0 : 0000000000000000 [ 1111.053290] Call trace: [ 1111.055728] Exception stack(0xffff00000801bcd0 to 0xffff00000801be10) [ 1111.062158] bcc0: 0000000000000000 0000000000000000 [ 1111.069978] bce0: 0000000000000614 ffff00000801be98 0000000000000010 ffff00000801bea0 [ 1111.077798] bd00: ffff80007fda9aa8 0000000000000000 0000000000000004 ffff00000801bea0 [ 1111.085618] bd20: 0000000000000001 ffff80007fda9af0 0000000000000040 ffff000008916788 [ 1111.093437] bd40: 0000000000000000 ffff0000089167b0 0000000000000058 ffff0000089167b0 [ 1111.101256] bd60: 0000000000000000 ffff8000787a81c0 0000000000000101 0000000000000000 [ 1111.109075] bd80: 0000000000000000 dead000000000200 0000000000000000 0000000000000000 [ 1111.116895] bda0: ffff000008c160c0 ffff000008bf87c8 ffff000008bf7018 ffff00000801be10 [ 1111.124715] bdc0: ffff0000080ff29c ffff00000801be10 0000000000000000 0000000000400145 [ 1111.132534] bde0: ffff8000787a81c0 ffff00000801bde8 0000ffffffffffff 000001029eb19be8 [ 1111.140353] be00: ffff00000801be10 0000000000000000 [ 1111.145220] [< (null)>] (null) [ 1111.149917] [<ffff0000080ff77c>] run_timer_softirq+0x184/0x398 [ 1111.155741] [<ffff000008081938>] __do_softirq+0x100/0x1fc [ 1111.161130] [<ffff0000080a2e28>] irq_exit+0x80/0xd8 [ 1111.166002] [<ffff0000080ea708>] __handle_domain_irq+0x88/0xb0 [ 1111.171825] [<ffff000008081678>] gic_handle_irq+0x68/0xb0 [ 1111.177213] Exception stack(0xffff0000090cbe30 to 0xffff0000090cbf70) [ 1111.183642] be20: 0000000000000020 0000000000000000 [ 1111.191461] be40: 0000000000000001 0000000000000000 00008000771af000 0000000000000000 [ 1111.199281] be60: ffff000008c95180 0000000000000000 ffff000008c19360 ffff0000090cbef0 [ 1111.207101] be80: 0000000000000810 0000000000000400 0000000000000098 ffff000000000000 [ 1111.214920] bea0: 0000000000000001 ffff0000089167b0 0000000000000000 ffff0000089167b0 [ 1111.222740] bec0: 0000000000000000 ffff000008c198e8 ffff000008bf7018 ffff000008c19000 [ 1111.230559] bee0: 0000000000000000 0000000000000000 ffff8000787a81c0 ffff000008018000 [ 1111.238380] bf00: ffff00000801c000 ffff00000913ba34 ffff8000787a81c0 ffff0000090cbf70 [ 1111.246199] bf20: ffff0000080857cc ffff0000090cbf70 ffff0000080857d0 0000000000400145 [ 1111.254020] bf40: ffff000008018000 ffff00000801c000 ffffffffffffffff ffff0000080fa574 [ 1111.261838] bf60: ffff0000090cbf70 ffff0000080857d0 [ 1111.266706] [<ffff0000080832e8>] el1_irq+0xe8/0x18c [ 1111.271576] [<ffff0000080857d0>] arch_cpu_idle+0x10/0x18 [ 1111.276880] [<ffff0000080d7de4>] do_idle+0xec/0x1b8 [ 1111.281748] [<ffff0000080d8020>] cpu_startup_entry+0x20/0x28 [ 1111.287399] [<ffff00000808f81c>] secondary_start_kernel+0x104/0x110 [ 1111.293662] Code: bad PC value [ 1111.296710] ---[ end trace 555b6ca4363c3edd ]--- [ 1111.301318] Kernel panic - not syncing: Fatal exception in interrupt [ 1111.307661] SMP: stopping secondary CPUs [ 1111.311574] Kernel Offset: disabled [ 1111.315053] CPU features: 0x0002000 [ 1111.318530] Memory Limit: none [ 1111.321575] Rebooting in 3 seconds.. With some added debug output / delays we were able to push the crash from the timer callback runner into the callback function and by that shedding some light on which object holding the timer gets corrupted: [ 401.720899] Unable to handle kernel read from unreadable memory at virtual address 00000868 [...] [ 402.335836] [<ffff0000088fafa4>] _raw_spin_lock_bh+0x14/0x48 [ 402.341548] [<ffff000000dbe684>] mesh_path_timer+0x10c/0x248 [mac80211] [ 402.348154] [<ffff0000080ff29c>] call_timer_fn.isra.27+0x24/0x78 [ 402.354150] [<ffff0000080ff77c>] run_timer_softirq+0x184/0x398 [ 402.359974] [<ffff000008081938>] __do_softirq+0x100/0x1fc [ 402.365362] [<ffff0000080a2e28>] irq_exit+0x80/0xd8 [ 402.370231] [<ffff0000080ea708>] __handle_domain_irq+0x88/0xb0 [ 402.376053] [<ffff000008081678>] gic_handle_irq+0x68/0xb0 The issue happens due to the following sequence of events: 1) mesh_path_start_discovery(): -> spin_unlock_bh(&mpath->state_lock) before mesh_path_sel_frame_tx() 2) mesh_path_free_rcu() -> del_timer_sync(&mpath->timer) [...] -> kfree_rcu(mpath) 3) mesh_path_start_discovery(): -> mod_timer(&mpath->timer, ...) [...] -> rcu_read_unlock() 4) mesh_path_free_rcu()'s kfree_rcu(): -> kfree(mpath) 5) mesh_path_timer() starts after timeout, using freed mpath object So a use-after-free issue due to a timer re-arming bug caused by an early spin-unlocking. This patch fixes this issue by re-checking if mpath is about to be free'd and if so bails out of re-arming the timer. Cc: [email protected] Fixes: 050ac52cbe1f ("mac80211: code for on-demand Hybrid Wireless Mesh Protocol") Cc: Simon Wunderlich <[email protected]> Signed-off-by: Linus Lüssing <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.