- 01 Sep, 2021 1 commit
-
-
Wang ShaoBo authored
use-after-free error in lock_sock_nested is reported: [ 179.140137][ T3731] ===================================================== [ 179.142675][ T3731] BUG: KMSAN: use-after-free in lock_sock_nested+0x280/0x2c0 [ 179.145494][ T3731] CPU: 4 PID: 3731 Comm: kworker/4:2 Not tainted 5.12.0-rc6+ #54 [ 179.148432][ T3731] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 179.151806][ T3731] Workqueue: events l2cap_chan_timeout [ 179.152730][ T3731] Call Trace: [ 179.153301][ T3731] dump_stack+0x24c/0x2e0 [ 179.154063][ T3731] kmsan_report+0xfb/0x1e0 [ 179.154855][ T3731] __msan_warning+0x5c/0xa0 [ 179.155579][ T3731] lock_sock_nested+0x280/0x2c0 [ 179.156436][ T3731] ? kmsan_get_metadata+0x116/0x180 [ 179.157257][ T3731] l2cap_sock_teardown_cb+0xb8/0x890 [ 179.158154][ T3731] ? __msan_metadata_ptr_for_load_8+0x10/0x20 [ 179.159141][ T3731] ? kmsan_get_metadata+0x116/0x180 [ 179.159994][ T3731] ? kmsan_get_shadow_origin_ptr+0x84/0xb0 [ 179.160959][ T3731] ? l2cap_sock_recv_cb+0x420/0x420 [ 179.161834][ T3731] l2cap_chan_del+0x3e1/0x1d50 [ 179.162608][ T3731] ? kmsan_get_metadata+0x116/0x180 [ 179.163435][ T3731] ? kmsan_get_shadow_origin_ptr+0x84/0xb0 [ 179.164406][ T3731] l2cap_chan_close+0xeea/0x1050 [ 179.165189][ T3731] ? kmsan_internal_unpoison_shadow+0x42/0x70 [ 179.166180][ T3731] l2cap_chan_timeout+0x1da/0x590 [ 179.167066][ T3731] ? __msan_metadata_ptr_for_load_8+0x10/0x20 [ 179.168023][ T3731] ? l2cap_chan_create+0x560/0x560 [ 179.168818][ T3731] process_one_work+0x121d/0x1ff0 [ 179.169598][ T3731] worker_thread+0x121b/0x2370 [ 179.170346][ T3731] kthread+0x4ef/0x610 [ 179.171010][ T3731] ? process_one_work+0x1ff0/0x1ff0 [ 179.171828][ T3731] ? kthread_blkcg+0x110/0x110 [ 179.172587][ T3731] ret_from_fork+0x1f/0x30 [ 179.173348][ T3731] [ 179.173752][ T3731] Uninit was created at: [ 179.174409][ T3731] kmsan_internal_poison_shadow+0x5c/0xf0 [ 179.175373][ T3731] kmsan_slab_free+0x76/0xc0 [ 179.176060][ T3731] kfree+0x3a5/0x1180 [ 179.176664][ T3731] __sk_destruct+0x8af/0xb80 [ 179.177375][ T3731] __sk_free+0x812/0x8c0 [ 179.178032][ T3731] sk_free+0x97/0x130 [ 179.178686][ T3731] l2cap_sock_release+0x3d5/0x4d0 [ 179.179457][ T3731] sock_close+0x150/0x450 [ 179.180117][ T3731] __fput+0x6bd/0xf00 [ 179.180787][ T3731] ____fput+0x37/0x40 [ 179.181481][ T3731] task_work_run+0x140/0x280 [ 179.182219][ T3731] do_exit+0xe51/0x3e60 [ 179.182930][ T3731] do_group_exit+0x20e/0x450 [ 179.183656][ T3731] get_signal+0x2dfb/0x38f0 [ 179.184344][ T3731] arch_do_signal_or_restart+0xaa/0xe10 [ 179.185266][ T3731] exit_to_user_mode_prepare+0x2d2/0x560 [ 179.186136][ T3731] syscall_exit_to_user_mode+0x35/0x60 [ 179.186984][ T3731] do_syscall_64+0xc5/0x140 [ 179.187681][ T3731] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 179.188604][ T3731] ===================================================== In our case, there are two Thread A and B: Context: Thread A: Context: Thread B: l2cap_chan_timeout() __se_sys_shutdown() l2cap_chan_close() l2cap_sock_shutdown() l2cap_chan_del() l2cap_chan_close() l2cap_sock_teardown_cb() l2cap_sock_teardown_cb() Once l2cap_sock_teardown_cb() excuted, this sock will be marked as SOCK_ZAPPED, and can be treated as killable in l2cap_sock_kill() if sock_orphan() has excuted, at this time we close sock through sock_close() which end to call l2cap_sock_kill() like Thread C: Context: Thread C: sock_close() l2cap_sock_release() sock_orphan() l2cap_sock_kill() #free sock if refcnt is 1 If C completed, Once A or B reaches l2cap_sock_teardown_cb() again, use-after-free happened. We should set chan->data to NULL if sock is destructed, for telling teardown operation is not allowed in l2cap_sock_teardown_cb(), and also we should avoid killing an already killed socket in l2cap_sock_close_cb(). Signed-off-by:Wang ShaoBo <bobo.shaobowang@huawei.com> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- 31 Aug, 2021 2 commits
-
-
Kiran K authored
Boot address was not getting updated when controller is present in boot mode which is required to move the controller from boot mode to operation mode after firmware download. This patch reads boot address even if controller is present in boot mode. Signed-off-by:
Kiran K <kiran.k@intel.com> Signed-off-by:
-
Kiran K authored
Cache Boot address present in firmware file which is later used in Intel_Soft_Reset command to bring controller from boot mode to operational mode. Signed-off-by:
-
- 30 Aug, 2021 37 commits
-
-
Luiz Augusto von Dentz authored
When connecting to a device using an RPA if the address has been resolved by the controller (types 0x02 and 0x03) the identity address shall be used as the actual RPA in the advertisement won't be visible to the host. Signed-off-by:
-
Luiz Augusto von Dentz authored
Address types ADDR_LE_DEV_PUBLIC_RESOLVED and ADDR_LE_DEV_RANDOM_RESOLVED shall be converted to ADDR_LE_PUBLIC and ADDR_LE_RANDOM repectively since they are not safe to be used beyond the scope of the events themselves. Signed-off-by:
-
Luiz Augusto von Dentz authored
When disconnecting the advertising shall be re-enabled only when the connection role is slave/peripheral as the central role use advertising to connect it could end up enabling the instance 0x00 if there are other advertising instances. Signed-off-by:
-
Takashi Iwai authored
The sco_send_frame() also takes lock_sock() during memcpy_from_msg() call that may be endlessly blocked by a task with userfaultd technique, and this will result in a hung task watchdog trigger. Just like the similar fix for hci_sock_sendmsg() in commit 92c685dc5de0 ("Bluetooth: reorganize functions..."), this patch moves the memcpy_from_msg() out of lock_sock() for addressing the hang. This should be the last piece for fixing CVE-2021-3640 after a few already queued fixes. Signed-off-by:Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Joseph Hwang authored
This patch sets up set_quality_report callback for Intel to set and reset the debug features. Reviewed-by:
Miao-chen Chou <mcchou@chromium.org> Signed-off-by:
Joseph Hwang <josephsih@chromium.org> Signed-off-by:
-
Joseph Hwang authored
This patch allows a user space process to enable/disable the quality report events dynamically through the set experimental feature mgmt interface. Since the quality report feature needs to invoke the callback function provided by the driver, i.e., hdev->set_quality_report, a valid controller index is required. Reviewed-by:
-
Joseph Hwang authored
This patch refactors the set_exp_feature with a feature table consisting of UUIDs and the corresponding callback functions. In this way, a new experimental feature setting function can be simply added with its UUID and callback function. Signed-off-by:
-
Chethan T N authored
This patch supports the link statistics telemetry events for intel controllers Reviewed-by:
Chethan T N <chethan.tumkur.narayan@intel.com> Signed-off-by:
-
Joseph Hwang authored
To avoid the overhead on both the controller and the host, the Intel link statistics telemetry events are disabled by default. Reviewed-by:
-
Brian Gix authored
Legacy (v2.0) controllers do not support Extended OOB Data used by SSP. Signed-off-by:
Brian Gix <brian.gix@intel.com> Signed-off-by:
-
Tetsuo Handa authored
Since userfaultfd mechanism allows sleeping with kernel lock held, avoiding page fault with kernel lock held where possible will make the module more robust. This patch just brings memcpy_from_msg() calls to out of sock lock. Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by:
-
Yajun Deng authored
Add a if statements to avoid the warning. Dan Carpenter report: The patch faf482ca: "net: ipv4: Move ip_options_fragment() out of loop" from Aug 23, 2021, leads to the following Smatch complaint: net/ipv4/ip_output.c:833 ip_do_fragment() warn: variable dereferenced before check 'iter.frag' (see line 828) Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: faf482ca ("net: ipv4: Move ip_options_fragment() out of loop") Link: https://lore.kernel.org/netdev/20210830073802.GR7722@kadam/T/#tSigned-off-by:
Yajun Deng <yajun.deng@linux.dev> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Dan Carpenter authored
These checks are still not strict enough. The main problem is that if "cb->type == QRTR_TYPE_NEW_SERVER" is true then "len - hdrlen" is guaranteed to be 4 but we need to be at least 16 bytes. In fact, we can reject everything smaller than sizeof(*pkt) which is 20 bytes. Also I don't like the ALIGN(size, 4). It's better to just insist that data is needs to be aligned at the start. Fixes: 0baa99ee ("net: qrtr: Allow non-immediate node routing") Signed-off-by:
-
Haimin Zhang authored
syzbot report an array-index-out-of-bounds in taprio_change index 16 is out of range for type '__u16 [16]' that's because mqprio->num_tc is lager than TC_MAX_QUEUE,so we check the return value of netdev_set_num_tc. Reported-by: syzbot+2b3e5fb6c7ef285a94f6@syzkaller.appspotmail.com Signed-off-by:
Haimin Zhang <tcs_kernel@tencent.com> Signed-off-by:
-
王贇 authored
In netlbl_cipsov4_add_std() when 'doi_def->map.std' alloc failed, we sometime observe panic: BUG: kernel NULL pointer dereference, address: ... RIP: 0010:cipso_v4_doi_free+0x3a/0x80 ... Call Trace: netlbl_cipsov4_add_std+0xf4/0x8c0 netlbl_cipsov4_add+0x13f/0x1b0 genl_family_rcv_msg_doit.isra.15+0x132/0x170 genl_rcv_msg+0x125/0x240 This is because in cipso_v4_doi_free() there is no check on 'doi_def->map.std' when doi_def->type got value 1, which is possibe, since netlbl_cipsov4_add_std() haven't initialize it before alloc 'doi_def->map.std'. This patch just add the check to prevent panic happen in similar cases. Reported-by:
Abaci <abaci@linux.alibaba.com> Signed-off-by:
Michael Wang <yun.wang@linux.alibaba.com> Signed-off-by:
-
David S. Miller authored
Eric Dumazet says: ==================== inet: make exception handling less predictible This second round of patches is addressing Keyu Man recommendations to make linux hosts more robust against a class of brute force attacks. ==================== Signed-off-by: -
Eric Dumazet authored
Even after commit 6457378f ("ipv4: use siphash instead of Jenkins in fnhe_hashfun()"), an attacker can still use brute force to learn some secrets from a victim linux host. One way to defeat these attacks is to make the max depth of the hash table bucket a random value. Before this patch, each bucket of the hash table used to store exceptions could contain 6 items under attack. After the patch, each bucket would contains a random number of items, between 6 and 10. The attacker can no longer infer secrets. This is slightly increasing memory size used by the hash table, by 50% in average, we do not expect this to be a problem. This patch is more complex than the prior one (IPv6 equivalent), because IPv4 was reusing the oldest entry. Since we need to be able to evict more than one entry per update_or_create_fnhe() call, I had to replace fnhe_oldest() with fnhe_remove_oldest(). Also note that we will queue extra kfree_rcu() calls under stress, which hopefully wont be a too big issue. Fixes: 4895c771 ("ipv4: Add FIB nexthop exceptions.") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Keyu Man <kman001@ucr.edu> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by:
David Ahern <dsahern@kernel.org> Tested-by:
-
Eric Dumazet authored
Even after commit 4785305c ("ipv6: use siphash in rt6_exception_hash()"), an attacker can still use brute force to learn some secrets from a victim linux host. One way to defeat these attacks is to make the max depth of the hash table bucket a random value. Before this patch, each bucket of the hash table used to store exceptions could contain 6 items under attack. After the patch, each bucket would contains a random number of items, between 6 and 10. The attacker can no longer infer secrets. This is slightly increasing memory size used by the hash table, we do not expect this to be a problem. Following patch is dealing with the same issue in IPv4. Fixes: 35732d01 ("ipv6: introduce a hash table to store dst cache") Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-nextDavid S. Miller authored
Pablo Neira Ayuso says: ==================== Netfilter updates for net-next The following patchset contains Netfilter updates for net-next: 1) Clean up and consolidate ct ecache infrastructure by merging ct and expect notifiers, from Florian Westphal. 2) Missing counters and timestamp in nfnetlink_queue and _log conntrack information. 3) Missing error check for xt_register_template() in iptables mangle, as a incremental fix for the previous pull request, also from Florian Westphal. 4) Add netfilter hooks for the SRv6 lightweigh tunnel driver, from Ryoga Sato. The hooks are enabled via nf_hooks_lwtunnel sysctl to make sure existing netfilter rulesets do not break. There is a static key to disable the hooks by default. The pktgen_bench_xmit_mode_netif_receive.sh shows no noticeable impact in the seg6_input path for non-netfilter users: similar numbers with and without this patch. This is a sample of the perf report output: 11.67% kpktgend_0 [ipv6] [k] ipv6_get_saddr_eval 7.89% kpktgend_0 [ipv6] [k] __ipv6_addr_label 7.52% kpktgend_0 [ipv6] [k] __ipv6_dev_get_saddr 6.63% kpktgend_0 [kernel.vmlinux] [k] asm_exc_nmi 4.74% kpktgend_0 [ipv6] [k] fib6_node_lookup_1 3.48% kpktgend_0 [kernel.vmlinux] [k] pskb_expand_head 3.33% kpktgend_0 [ipv6] [k] ip6_rcv_core.isra.29 3.33% kpktgend_0 [ipv6] [k] seg6_do_srh_encap 2.53% kpktgend_0 [ipv6] [k] ipv6_dev_get_saddr 2.45% kpktgend_0 [ipv6] [k] fib6_table_lookup 2.24% kpktgend_0 [kernel.vmlinux] [k] ___cache_free 2.16% kpktgend_0 [ipv6] [k] ip6_pol_route 2.11% kpktgend_0 [kernel.vmlinux] [k] __ipv6_addr_type ==================== Signed-off-by: -
David S. Miller authored
Linus Walleij says: ==================== IXP46x PTP Timer clean-up and DT ChangeLog v2->v3: - Dropped the patch enabling compile tests: we are still dependent on some machine-specific headers. The plan is to get rid of this after device tree conversion. We include one of the compile testing fixes anyway, because it is nice to have fixed. - Rebased on the latest net-next ==================== Signed-off-by: -
Linus Walleij authored
This adds device tree probing support for the PTP module adjacent to the ethernet module. It is pretty straight forward, all resources are in the device tree as they come to the platform device. Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Linus Walleij authored
This adds device tree bindings for the IXP46x PTP Timer, a companion to the IXP4xx ethernet in newer platforms. Cc: devicetree@vger.kernel.org Cc: Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Linus Walleij authored
The driver is being passed interrupts, then looking up the same interrupts as GPIOs a second time to convert them into interrupts and set properties on them. This is pointless: the GPIO and irqchip APIs of a GPIO chip are orthogonal. Just request the interrupts and be done with it, drop reliance on any GPIO functions or definitions. Use devres-managed functions and add a small devress quirk to unregister the clock as well and we can rely on devres to handle all the resources and cut down a bunch of boilerplate in the process. Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
Change the driver to use portable integer types to avoid warnings during compile testing, including: drivers/net/ethernet/xscale/ixp4xx_eth.c:721:21: error: cast to 'u32 *' (aka 'unsigned int *') from smaller integer type 'int' [-Werror,-Wint-to-pointer-cast] memcpy_swab32(mem, (u32 *)((int)skb->data & ~3), bytes / 4); ^ drivers/net/ethernet/xscale/ixp4xx_eth.c:963:12: error: incompatible pointer types passing 'u32 *' (aka 'unsigned int *') to parameter of type 'dma_addr_t *' (aka 'unsigned long long *') [-Werror,-Wincompatible-pointer-types] &port->desc_tab_phys))) ^~~~~~~~~~~~~~~~~~~~ include/linux/dmapool.h:27:20: note: passing argument to parameter 'handle' here dma_addr_t *handle); ^ Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
After the recent ixp4xx cleanups, the ptp driver has gained a build failure in some configurations: drivers/net/ethernet/xscale/ptp_ixp46x.c: In function 'ptp_ixp_init': drivers/net/ethernet/xscale/ptp_ixp46x.c:290:51: error: 'IXP4XX_TIMESYNC_BASE_VIRT' undeclared (first use in this function) Avoid the last bit of hardcoded constants from platform headers by turning the ptp driver bit into a platform driver and passing the IRQ and MMIO address as resources. This is a bit tricky: - The interface between the two drivers is now the new ixp46x_ptp_find() function, replacing the global ixp46x_phc_index variable. The call is done as late as possible, in hwtstamp_set(), to ensure that the ptp device is fully probed. - As the ptp driver is now called by the network driver, the link dependency is reversed, which in turn requires a small Makefile hack - The GPIO number is still left hardcoded. This is clearly not great, but it can be addressed later. Note that commit 98ac0cc2 ("ARM: ixp4xx: Convert to MULTI_IRQ_HANDLER") changed the IRQ number to something meaningless. Passing the correct IRQ in a resource fixes this. - When the PTP driver is disabled, ethtool .get_ts_info() now correctly lists only software timestamping regardless of the hardware. Signed-off-by:
-
David S. Miller authored
Guangbin Huang says: ==================== net: hns3: add some cleanups This series includes some cleanups for the HNS3 ethernet driver. ==================== Signed-off-by: -
Hao Chen authored
The parameter name of hclge_ptp_clean_tx_hwts() in declaration is "dev", but the definition of this function is used the common name "hdev" as other functions, so modify it. Signed-off-by:
Hao Chen <chenhao288@hisilicon.com> Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
-
Hao Chen authored
Replace the "? :" statement wich max() to simplify code. Signed-off-by:
-
Hao Chen authored
The type of tqp_vector->vector_irq is int, so modify its print format to "%d". Signed-off-by:
-
Guangbin Huang authored
To improve flexibility, simplicity and maintainability to dump info of every element of tm priority, add a struct hclge_dbg_item array of tm priority and fill string of every data according to this array. Signed-off-by:
-
Guangbin Huang authored
This patch reconstructs function hclge_ets_validate() to reduce the code cycle complexity and make code more concise. Signed-off-by:
-
Peng Li authored
This patch reconstructs function hns3_self_test to reduce the code cycle complexity and make code more concise. Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
-
Jiaran Zhang authored
To make the format of each member initialization of structure array clearer, initialize each member on a separate line. Signed-off-by:
Jiaran Zhang <zhangjiaran@huawei.com> Signed-off-by:
-
David S. Miller authored
Michael Chan says: ==================== bnxt_en: Implement new driver APIs to send FW messages The current driver APIs to send messages to the firmware allow only one outstanding message in flight. There is only one buffer for the firmware response for each firmware channel. To send a firmware message, all callers must take a mutex and it is released after the firmware response has been read. This scheme does not allow multiple firmware messages in flight. Firmware may take a long time to respond to some messages (e.g. NVRAM related ones) and this causes the mutex to be held for a long time, blocking other callers. This patchset intoduces the new driver APIs to address the above shortcomings. The new APIs are compatible with new and old firmware. But the new deferred firmware response mechanism will require newer firmware in order to allow multiple outstanding firmware commands. All callers are updated to use the new APIs. v2: Patch 4 and patch 9 updated to fix issues reported by test robot ==================== Signed-off-by: -
Edwin Peer authored
Add infrastructure to maintain a pending list of HWRM commands awaiting completion and reduce the scope of the hwrm_cmd_lock mutex so that it protects only the request mailbox. The mailbox is free to use for one or more concurrent commands after receiving deferred response events. For uniformity and completeness, use the same pending list for collecting completions for commands that respond via a completion ring. These commands are only used for freeing rings and for IRQ test and we only support one such command in flight. Note deferred responses are also only supported on the main channel. The secondary channel (KONG) does not support deferred responses. Signed-off-by:
Edwin Peer <edwin.peer@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Edwin Peer authored
There are no longer any callers relying on the old API. Signed-off-by:
-
Edwin Peer authored
The conversion follows this general pattern for most of the calls: 1. The input message is changed from a stack variable initialized using bnxt_hwrm_cmd_hdr_init() to a pointer allocated and intialized using hwrm_req_init(). 2. If we don't need to read the firmware response, the hwrm_send_message() call is replaced with hwrm_req_send(). 3. If we need to read the firmware response, the mutex lock is replaced by hwrm_req_hold() to hold the response. When the response is read, the mutex unlock is replaced by hwrm_req_drop(). If additional DMA buffers are needed for firmware response data, the hwrm_req_dma_slice() is used instead of calling dma_alloc_coherent(). Some minor refactoring is also done while doing these conversions. v2: Fix unintialized variable warnings in __bnxt_hwrm_get_tx_rings() and bnxt_approve_mac() Signed-off-by:
-
