- 12 Dec, 2022 17 commits
-
-
Florian Fainelli authored
Emails to Joakim Zhang bounce, update the list of maintainers per feedback from Clark Wang and designate Wei Fang as the primary maintainer. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Pilmore authored
TX/RX callback handlers (ntb_netdev_tx_handler(), ntb_netdev_rx_handler()) can be called in interrupt context via the DMA framework when the respective DMA operations have completed. As such, any calls by these routines to free skb's, should use the interrupt context safe dev_kfree_skb_any() function. Previously, these callback handlers would call the interrupt unsafe version of dev_kfree_skb(). This has not presented an issue on Intel IOAT DMA engines as that driver utilizes tasklets rather than a hard interrupt handler, like the AMD PTDMA DMA driver. On AMD systems, a kernel WARNING message is encountered, which is being issued from skb_release_head_state() due to in_hardirq() being true. Besides the user visible WARNING from the kernel, the other symptom of this bug was that TCP/IP performance across the ntb_netdev interface was very poor, i.e. approximately an order of magnitude below what was expected. With the repair to use dev_kfree_skb_any(), kernel WARNINGs from skb_release_head_state() ceased and TCP/IP performance, as measured by iperf, was on par with expected results, approximately 20 Gb/s on AMD Milan based server. Note that this performance is comparable with Intel based servers. Fixes: 765ccc7b ("ntb_netdev: correct skb leak") Fixes: 548c237c ("net: Add support for NTB virtual ethernet device") Signed-off-by:
Eric Pilmore <epilmore@gigaio.com> Reviewed-by:
Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/20221209000659.8318-1-epilmore@gigaio.comSigned-off-by:
-
Jerry Ray authored
This patch fixes an issue where a read failure of a port statistic counter will return unknown results. While it is highly unlikely the read will ever fail, it is much cleaner to return a zero for the stat count. Fixes: a1292595 ("net: dsa: add new DSA switch driver for the SMSC-LAN9303") Signed-off-by:
Jerry Ray <jerry.ray@microchip.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
-
Tom Lendacky authored
There are cables that exist that can support speeds in excess of 10GbE. The driver, however, restricts the EEPROM advertised nominal bitrate to a specific range, which can prevent usage of cables that can support, for example, up to 25GbE. Rather than checking that an active or passive cable supports a specific range, only check for a minimum supported speed. Fixes: abf0a1c2 ("amd-xgbe: Add support for SFP+ modules") Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Tom Lendacky authored
SFP+ active and passive cables are copper cables with fixed SFP+ end connectors. Due to a misinterpretation of this, SFP+ active cables could end up not being recognized, causing the driver to fail to establish a connection. Introduce a new enum in SFP+ cable types, XGBE_SFP_CABLE_FIBER, that is the default cable type, and handle active and passive cables when they are specifically detected. Fixes: abf0a1c2 ("amd-xgbe: Add support for SFP+ modules") Signed-off-by:
-
Yang Yingliang authored
If register unix_stream_proto returns error, unix_dgram_proto needs be unregistered. Fixes: 94531cfc ("af_unix: Add unix_stream_proto for sockmap") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Reviewed-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by:
-
Richard Gobert authored
Change the behaviour of ip6_datagram_connect to consider the interface set by the IPV6_UNICAST_IF socket option, similarly to udpv6_sendmsg. This change is the IPv6 counterpart of the fix for IP_UNICAST_IF. The tests introduced by that patch showed that the incorrect behavior is present in IPv6 as well. This patch fixes the broken test. Reported-by:
kernel test robot <oliver.sang@intel.com> Link: https://lore.kernel.org/r/202210062117.c7eef1a3-oliver.sang@intel.com Fixes: 0e4d3547 ("net-next: Fix IP_UNICAST_IF option behavior for connected sockets") Signed-off-by:
Richard Gobert <richardbgobert@gmail.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
-
David S. Miller authored
Yang Yingliang says: ==================== net: don't call dev_kfree_skb() under spin_lock_irqsave() It is not allowed to call consume_skb() from hardware interrupt context or with interrupts being disabled. This patchset replace dev_kfree_skb() with dev_kfree_skb_irq/dev_consume_skb_irq() under spin_lock_irqsave() in some drivers, or move dev_kfree_skb() after spin_unlock_irqrestore(). v2 -> v3: Update commit message, and change to use dev_kfree_skb_irq() in patch #1, #3. v1 -> v2: patch #2 Move dev_kfree_skb() after spin_unlock_irqrestore() ==================== Signed-off-by: -
Yang Yingliang authored
It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In these two cases, dev_kfree_skb() is called consume the xmited SKB, so replace it with dev_consume_skb_irq(). Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Yang Yingliang authored
It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In scc_discard_buffers(), dev_kfree_skb() is called to discard the SKBs, so replace it with dev_kfree_skb_irq(). In scc_net_tx(), dev_kfree_skb() is called to drop the SKB that exceed queue length, so replace it with dev_kfree_skb_irq(). Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Yang Yingliang authored
It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. In this case, the lock is used to protected 'bp', so we can move dev_kfree_skb() after the spin_unlock_irqrestore(). Fixes: 47964174 ("dnet: Dave DNET ethernet controller driver (updated)") Signed-off-by:
-
Yang Yingliang authored
It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In this case, dev_kfree_skb() is called in xemaclite_tx_timeout() to drop the SKB, when tx timeout, so replace it with dev_kfree_skb_irq(). Fixes: bb81b2dd ("net: add Xilinx emac lite device driver") Signed-off-by:
-
Yang Yingliang authored
It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In this case, dev_kfree_skb() is called in bmac_tx_timeout() to drop the SKB, when tx timeout, so replace it with dev_kfree_skb_irq(). Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Yang Yingliang authored
It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In this case, dev_kfree_skb() is called in mace_tx_timeout() to drop the SKB, when tx timeout, so replace it with dev_kfree_skb_irq(). Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Hangbin Liu authored
There is a race condition in vxlan that when deleting a vxlan device during receiving packets, there is a possibility that the sock is released after getting vxlan_sock vs from sk_user_data. Then in later vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got NULL pointer dereference. e.g. #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757 #1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d #2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48 #3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b #4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb #5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542 #6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62 [exception RIP: vxlan_ecn_decapsulate+0x3b] RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246 RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000 RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700 RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700 R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan] #8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507 #9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45 #10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807 #11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951 #12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde #13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b #14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139 #15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a #16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3 #17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3 Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh Fix this by waiting for all sk_user_data reader to finish before releasing the sock. Reported-by:Jianlin Shi <jishi@redhat.com> Suggested-by:
Jakub Sitnicki <jakub@cloudflare.com> Fixes: 6a93cc90 ("udp-tunnel: Add a few more UDP tunnel APIs") Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
-
Li Zetao authored
There are two memory leaks reported by kmemleak: unreferenced object 0xffff888114b20200 (size 128): comm "modprobe", pid 4846, jiffies 4295146524 (age 401.345s) hex dump (first 32 bytes): e0 62 57 09 81 88 ff ff e0 62 57 09 81 88 ff ff .bW......bW..... 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff815bcd82>] kmalloc_trace+0x22/0x60 [<ffffffff83d35c78>] __hw_addr_add_ex+0x198/0x6c0 [<ffffffff83d3989d>] dev_addr_init+0x13d/0x230 [<ffffffff83d1063d>] alloc_netdev_mqs+0x10d/0xe50 [<ffffffff82b4a06e>] alloc_hdlcdev+0x2e/0x80 [<ffffffffa016a741>] fst_add_one+0x601/0x10e0 [farsync] ... unreferenced object 0xffff88810b85b000 (size 1024): comm "modprobe", pid 4846, jiffies 4295146523 (age 401.346s) hex dump (first 32 bytes): 00 00 b0 02 00 c9 ff ff 00 70 0a 00 00 c9 ff ff .........p...... 00 00 00 f2 00 00 00 f3 0a 00 00 00 02 00 00 00 ................ backtrace: [<ffffffff815bcd82>] kmalloc_trace+0x22/0x60 [<ffffffffa016a294>] fst_add_one+0x154/0x10e0 [farsync] [<ffffffff82060e83>] local_pci_probe+0xd3/0x170 ... The root cause is traced to the netdev and fst_card_info are not freed when removes one fst in fst_remove_one(), which may trigger oom if repeated insmod and rmmod module. Fix it by adding free_netdev() and kfree() in fst_remove_one(), just as the operations on the error handling path in fst_add_one(). Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:Li Zetao <lizetao1@huawei.com> Reviewed-by:
-
Yang Yingliang authored
It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In this case, dev_kfree_skb() is called in free_tx_buffers() to drop the SKBs in tx buffers, when the card is down, so replace it with dev_kfree_skb_irq() here. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
- 09 Dec, 2022 5 commits
-
-
Yuan Can authored
If vp alloc failed in qlcnic_sriov_init(), all previously allocated vp needs to be freed. Fixes: f197a7aa ("qlcnic: VF-PF communication channel implementation") Signed-off-by:
Yuan Can <yuancan@huawei.com> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
-
Gaosheng Cui authored
The bitmap_free() should be called to free priv->af_xdp_zc_qps when create_singlethread_workqueue() fails, otherwise there will be a memory leak, so we add the err path error_wq_init to fix it. Fixes: bba2556e ("net: stmmac: Enable RX via AF_XDP zero-copy") Signed-off-by:
Gaosheng Cui <cuigaosheng1@huawei.com> Reviewed-by:
-
Zhang Changzhong authored
The skb allocated by stmmac_test_get_arp_skb() hasn't been released in some error handling case, which will lead to a memory leak. Fix this up by adding kfree_skb() to release skb. Compile tested only. Fixes: 5e3fb0a6 ("net: stmmac: selftests: Implement the ARP Offload test") Signed-off-by:
Zhang Changzhong <zhangchangzhong@huawei.com> Signed-off-by:
-
Yongqiang Liu authored
When eisa_driver_register() or tc_register_driver() failed, the modprobe defxx would fail with some err log as follows: Error: Driver 'defxx' is already registered, aborting... Fix this issue by adding err hanling in dfx_init(). Fixes: e89a2cfb ("[TC] defxx: TURBOchannel support") Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com> Reviewed-by:
-
Artem Chernyshev authored
vmci_transport_dgram_enqueue() does not check the return value of memcpy_from_msg(). If memcpy_from_msg() fails, it is possible that uninitialized memory contents are sent unintentionally instead of user's message in the datagram to the destination. Return with an error if memcpy_from_msg() fails. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 0f7db23a ("vmci_transport: switch ->enqeue_dgram, ->enqueue_stream and ->dequeue_stream to msghdr") Signed-off-by:
Artem Chernyshev <artem.chernyshev@red-soft.ru> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Vishnu Dasa <vdasa@vmware.com> Signed-off-by:
-
- 08 Dec, 2022 18 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds authored
Pull networking fixes from Jakub Kicinski: "Including fixes from bluetooth, can and netfilter. Current release - new code bugs: - bonding: ipv6: correct address used in Neighbour Advertisement parsing (src vs dst typo) - fec: properly scope IRQ coalesce setup during link up to supported chips only Previous releases - regressions: - Bluetooth fixes for fake CSR clones (knockoffs): - re-add ERR_DATA_REPORTING quirk - fix crash when device is replugged - Bluetooth: - silence a user-triggerable dmesg error message - L2CAP: fix u8 overflow, oob access - correct vendor codec definition - fix support for Read Local Supported Codecs V2 - ti: am65-cpsw: fix RGMII configuration at SPEED_10 - mana: fix race on per-CQ variable NAPI work_done Previous releases - always broken: - af_unix: diag: fetch user_ns from in_skb in unix_diag_get_exact(), avoid null-deref - af_can: fix NULL pointer dereference in can_rcv_filter - can: slcan: fix UAF with a freed work - can: can327: flush TX_work on ldisc .close() - macsec: add missing attribute validation for offload - ipv6: avoid use-after-free in ip6_fragment() - nft_set_pipapo: actually validate intervals in fields after the first one - mvneta: prevent oob access in mvneta_config_rss() - ipv4: fix incorrect route flushing when table ID 0 is used, or when source address is deleted - phy: mxl-gpy: add workaround for IRQ bug on GPY215B and GPY215C" * tag 'net-6.1-rc9' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (77 commits) net: dsa: sja1105: avoid out of bounds access in sja1105_init_l2_policing() s390/qeth: fix use-after-free in hsci macsec: add missing attribute validation for offload net: mvneta: Fix an out of bounds check net: thunderbolt: fix memory leak in tbnet_open() ipv6: avoid use-after-free in ip6_fragment() net: plip: don't call kfree_skb/dev_kfree_skb() under spin_lock_irq() net: phy: mxl-gpy: add MDINT workaround net: dsa: mv88e6xxx: accept phy-mode = "internal" for internal PHY ports xen/netback: don't call kfree_skb() under spin_lock_irqsave() dpaa2-switch: Fix memory leak in dpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove() ethernet: aeroflex: fix potential skb leak in greth_init_rings() tipc: call tipc_lxc_xmit without holding node_read_lock can: esd_usb: Allow REC and TEC to return to zero can: can327: flush TX_work on ldisc .close() can: slcan: fix freed work crash can: af_can: fix NULL pointer dereference in can_rcv_filter net: dsa: sja1105: fix memory leak in sja1105_setup_devlink_regions() ipv4: Fix incorrect route flushing when table ID 0 is used ipv4: Fix incorrect route flushing when source address is deleted ... -
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hidLinus Torvalds authored
Pull HID fixes from Jiri Kosina: "A regression fix for handling Logitech HID++ devices and memory corruption fixes: - regression fix (revert) for catch-all handling of Logitech HID++ Bluetooth devices; there are devices that turn out not to work with this, and the root cause is yet to be properly understood. So we are dropping it for now, and it will be revisited for 6.2 or 6.3 (Benjamin Tissoires) - memory corruption fix in HID core (ZhangPeng) - memory corruption fix in hid-lg4ff (Anastasia Belova) - Kconfig fix for I2C_HID (Benjamin Tissoires) - a few device-id specific quirks that piggy-back on top of the important fixes above" * tag 'for-linus-2022120801' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: Revert "HID: logitech-hidpp: Enable HID++ for all the Logitech Bluetooth devices" Revert "HID: logitech-hidpp: Remove special-casing of Bluetooth devices" HID: usbhid: Add ALWAYS_POLL quirk for some mice HID: core: fix shift-out-of-bounds in hid_report_raw_event HID: uclogic: Add HID_QUIRK_HIDINPUT_FORCE quirk HID: fix I2C_HID not selected when I2C_HID_OF_ELAN is HID: hid-lg4ff: Add check for empty lbuf HID: ite: Enable QUIRK_TOUCHPAD_ON_OFF_REPORT on Acer Aspire Switch V 10 HID: uclogic: Fix frame templates for big endian architectures -
git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds authored
Pull ARM SoC fix from Arnd Bergmann: "One last build fix came in, addressing a link failure when building without CONFIG_OUTER_CACHE" * tag 'soc-fixes-6.1-5' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: at91: fix build for SAMA5D3 w/o L2 cache
-
Benjamin Tissoires authored
This reverts commit 532223c8. As reported in [0], hid-logitech-hidpp now binds on all bluetooth mice, but there are corner cases where hid-logitech-hidpp just gives up on the mouse. This leads the end user with a dead mouse. Given that we are at -rc8, we are definitively too late to find a proper fix. We already identified 2 issues less than 24 hours after the bug report. One in that ->match() was never designed to be used anywhere else than in hid-generic, and the other that hid-logitech-hidpp has corner cases where it gives up on devices it is not supposed to. So we have no choice but postpone this patch to the next kernel release. [0] https://lore.kernel.org/linux-input/CAJZ5v0g-_o4AqMgNwihCb0jrwrcJZfRrX=jv8aH54WNKO7QB8A@mail.gmail.com/Reported-by:
Rafael J . Wysocki <rjw@rjwysocki.net> Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz>
-
Benjamin Tissoires authored
This reverts commit 8544c812. We need to revert commit 532223c8 ("HID: logitech-hidpp: Enable HID++ for all the Logitech Bluetooth devices") because that commit might make hid-logitech-hidpp bind on mice that are not well enough supported by hid-logitech-hidpp, and the end result is that the probe of those mice is now returning -ENODEV, leaving the end user with a dead mouse. Given that commit 8544c812 ("HID: logitech-hidpp: Remove special-casing of Bluetooth devices") is a direct dependency of 532223c8, revert it too. Note that this also adapt according to commit 908d325e ("HID: logitech-hidpp: Detect hi-res scrolling support") to re-add support of the devices that were removed from that commit too. I have locally an MX Master and I tested this device with that revert, ensuring we still have high-res scrolling. Reported-by:
-
Linus Torvalds authored
Merge tag 'loongarch-fixes-6.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson Pull LoongArch fixes from Huacai Chen: "Export smp_send_reschedule() for modules use, fix a huge page entry update issue, and add documents for booting description" * tag 'loongarch-fixes-6.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: docs/zh_CN: Add LoongArch booting description's translation docs/LoongArch: Add booting description LoongArch: mm: Fix huge page entry update for virtual machine LoongArch: Export symbol for function smp_send_reschedule()
-
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tipLinus Torvalds authored
Pull xen fix from Juergen Gross: "A single fix for the recent security issue XSA-423" * tag 'for-linus-xsa-6.1-rc9b-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen/netback: fix build warning
-
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linuxLinus Torvalds authored
Pull gpio fixes from Bartosz Golaszewski: - fix a memory leak in gpiolib core - fix reference leaks in gpio-amd8111 and gpio-rockchip * tag 'gpio-fixes-for-v6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpio/rockchip: fix refcount leak in rockchip_gpiolib_register() gpio: amd8111: Fix PCI device reference count leak gpiolib: fix memory leak in gpiochip_setup_dev()
-
git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libataLinus Torvalds authored
Pull ATA fix from Damien Le Moal: - Avoid a NULL pointer dereference in the libahci platform code that can happen on initialization when a device tree does not specify names for the adapter clocks (from Anders) * tag 'ata-6.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata: ata: libahci_platform: ahci_platform_find_clk: oops, NULL pointer
-
Tejun Heo authored
memcg_write_event_control() accesses the dentry->d_name of the specified control fd to route the write call. As a cgroup interface file can't be renamed, it's safe to access d_name as long as the specified file is a regular cgroup file. Also, as these cgroup interface files can't be removed before the directory, it's safe to access the parent too. Prior to 347c4a87 ("memcg: remove cgroup_event->cft"), there was a call to __file_cft() which verified that the specified file is a regular cgroupfs file before further accesses. The cftype pointer returned from __file_cft() was no longer necessary and the commit inadvertently dropped the file type check with it allowing any file to slip through. With the invarients broken, the d_name and parent accesses can now race against renames and removals of arbitrary files and cause use-after-free's. Fix the bug by resurrecting the file type check in __file_cft(). Now that cgroupfs is implemented through kernfs, checking the file operations needs to go through a layer of indirection. Instead, let's check the superblock and dentry type. Signed-off-by:
Tejun Heo <tj@kernel.org> Fixes: 347c4a87 ("memcg: remove cgroup_event->cft") Cc: stable@kernel.org # v3.14+ Reported-by:
Jann Horn <jannh@google.com> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Acked-by:
Roman Gushchin <roman.gushchin@linux.dev> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Radu Nicolae Pirea (OSS) authored
The SJA1105 family has 45 L2 policing table entries (SJA1105_MAX_L2_POLICING_COUNT) and SJA1110 has 110 (SJA1110_MAX_L2_POLICING_COUNT). Keeping the table structure but accounting for the difference in port count (5 in SJA1105 vs 10 in SJA1110) does not fully explain the difference. Rather, the SJA1110 also has L2 ingress policers for multicast traffic. If a packet is classified as multicast, it will be processed by the policer index 99 + SRCPORT. The sja1105_init_l2_policing() function initializes all L2 policers such that they don't interfere with normal packet reception by default. To have a common code between SJA1105 and SJA1110, the index of the multicast policer for the port is calculated because it's an index that is out of bounds for SJA1105 but in bounds for SJA1110, and a bounds check is performed. The code fails to do the proper thing when determining what to do with the multicast policer of port 0 on SJA1105 (ds->num_ports = 5). The "mcast" index will be equal to 45, which is also equal to table->ops->max_entry_count (SJA1105_MAX_L2_POLICING_COUNT). So it passes through the check. But at the same time, SJA1105 doesn't have multicast policers. So the code programs the SHARINDX field of an out-of-bounds element in the L2 Policing table of the static config. The comparison between index 45 and 45 entries should have determined the code to not access this policer index on SJA1105, since its memory wasn't even allocated. With enough bad luck, the out-of-bounds write could even overwrite other valid kernel data, but in this case, the issue was detected using KASAN. Kernel log: sja1105 spi5.0: Probed switch chip: SJA1105Q ================================================================== BUG: KASAN: slab-out-of-bounds in sja1105_setup+0x1cbc/0x2340 Write of size 8 at addr ffffff880bd57708 by task kworker/u8:0/8 ... Workqueue: events_unbound deferred_probe_work_func Call trace: ... sja1105_setup+0x1cbc/0x2340 dsa_register_switch+0x1284/0x18d0 sja1105_probe+0x748/0x840 ... Allocated by task 8: ... sja1105_setup+0x1bcc/0x2340 dsa_register_switch+0x1284/0x18d0 sja1105_probe+0x748/0x840 ... Fixes: 38fbe91f ("net: dsa: sja1105: configure the multicast policers, if present") CC: stable@vger.kernel.org # 5.15+ Signed-off-by:
Radu Nicolae Pirea (OSS) <radu-nicolae.pirea@oss.nxp.com> Reviewed-by:
-
Alexandra Winter authored
KASAN found that addr was dereferenced after br2dev_event_work was freed. ================================================================== BUG: KASAN: use-after-free in qeth_l2_br2dev_worker+0x5ba/0x6b0 Read of size 1 at addr 00000000fdcea440 by task kworker/u760:4/540 CPU: 17 PID: 540 Comm: kworker/u760:4 Tainted: G E 6.1.0-20221128.rc7.git1.5aa3bed4ce83.300.fc36.s390x+kasan #1 Hardware name: IBM 8561 T01 703 (LPAR) Workqueue: 0.0.8000_event qeth_l2_br2dev_worker Call Trace: [<000000016944d4ce>] dump_stack_lvl+0xc6/0xf8 [<000000016942cd9c>] print_address_description.constprop.0+0x34/0x2a0 [<000000016942d118>] print_report+0x110/0x1f8 [<0000000167a7bd04>] kasan_report+0xfc/0x128 [<000000016938d79a>] qeth_l2_br2dev_worker+0x5ba/0x6b0 [<00000001673edd1e>] process_one_work+0x76e/0x1128 [<00000001673ee85c>] worker_thread+0x184/0x1098 [<000000016740718a>] kthread+0x26a/0x310 [<00000001672c606a>] __ret_from_fork+0x8a/0xe8 [<00000001694711da>] ret_from_fork+0xa/0x40 Allocated by task 108338: kasan_save_stack+0x40/0x68 kasan_set_track+0x36/0x48 __kasan_kmalloc+0xa0/0xc0 qeth_l2_switchdev_event+0x25a/0x738 atomic_notifier_call_chain+0x9c/0xf8 br_switchdev_fdb_notify+0xf4/0x110 fdb_notify+0x122/0x180 fdb_add_entry.constprop.0.isra.0+0x312/0x558 br_fdb_add+0x59e/0x858 rtnl_fdb_add+0x58a/0x928 rtnetlink_rcv_msg+0x5f8/0x8d8 netlink_rcv_skb+0x1f2/0x408 netlink_unicast+0x570/0x790 netlink_sendmsg+0x752/0xbe0 sock_sendmsg+0xca/0x110 ____sys_sendmsg+0x510/0x6a8 ___sys_sendmsg+0x12a/0x180 __sys_sendmsg+0xe6/0x168 __do_sys_socketcall+0x3c8/0x468 do_syscall+0x22c/0x328 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 Freed by task 540: kasan_save_stack+0x40/0x68 kasan_set_track+0x36/0x48 kasan_save_free_info+0x4c/0x68 ____kasan_slab_free+0x14e/0x1a8 __kasan_slab_free+0x24/0x30 __kmem_cache_free+0x168/0x338 qeth_l2_br2dev_worker+0x154/0x6b0 process_one_work+0x76e/0x1128 worker_thread+0x184/0x1098 kthread+0x26a/0x310 __ret_from_fork+0x8a/0xe8 ret_from_fork+0xa/0x40 Last potentially related work creation: kasan_save_stack+0x40/0x68 __kasan_record_aux_stack+0xbe/0xd0 insert_work+0x56/0x2e8 __queue_work+0x4ce/0xd10 queue_work_on+0xf4/0x100 qeth_l2_switchdev_event+0x520/0x738 atomic_notifier_call_chain+0x9c/0xf8 br_switchdev_fdb_notify+0xf4/0x110 fdb_notify+0x122/0x180 fdb_add_entry.constprop.0.isra.0+0x312/0x558 br_fdb_add+0x59e/0x858 rtnl_fdb_add+0x58a/0x928 rtnetlink_rcv_msg+0x5f8/0x8d8 netlink_rcv_skb+0x1f2/0x408 netlink_unicast+0x570/0x790 netlink_sendmsg+0x752/0xbe0 sock_sendmsg+0xca/0x110 ____sys_sendmsg+0x510/0x6a8 ___sys_sendmsg+0x12a/0x180 __sys_sendmsg+0xe6/0x168 __do_sys_socketcall+0x3c8/0x468 do_syscall+0x22c/0x328 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 Second to last potentially related work creation: kasan_save_stack+0x40/0x68 __kasan_record_aux_stack+0xbe/0xd0 kvfree_call_rcu+0xb2/0x760 kernfs_unlink_open_file+0x348/0x430 kernfs_fop_release+0xc2/0x320 __fput+0x1ae/0x768 task_work_run+0x1bc/0x298 exit_to_user_mode_prepare+0x1a0/0x1a8 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 The buggy address belongs to the object at 00000000fdcea400 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 64 bytes inside of 96-byte region [00000000fdcea400, 00000000fdcea460) The buggy address belongs to the physical page: page:000000005a9c26e8 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xfdcea flags: 0x3ffff00000000200(slab|node=0|zone=1|lastcpupid=0x1ffff) raw: 3ffff00000000200 0000000000000000 0000000100000122 000000008008cc00 raw: 0000000000000000 0020004100000000 ffffffff00000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: 00000000fdcea300: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc 00000000fdcea380: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc >00000000fdcea400: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ 00000000fdcea480: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc 00000000fdcea500: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ================================================================== Fixes: f7936b7b ("s390/qeth: Update MACs of LEARNING_SYNC device") Reported-by:Thorsten Winkler <twinkler@linux.ibm.com> Signed-off-by:
Alexandra Winter <wintera@linux.ibm.com> Reviewed-by:
Wenjia Zhang <wenjia@linux.ibm.com> Reviewed-by:
-
Emeel Hakim authored
Add missing attribute validation for IFLA_MACSEC_OFFLOAD to the netlink policy. Fixes: 791bb3fc ("net: macsec: add support for specifying offload upon link creation") Signed-off-by:
Emeel Hakim <ehakim@nvidia.com> Reviewed-by:
Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/20221207101618.989-1-ehakim@nvidia.comSigned-off-by:
-
Dan Carpenter authored
In an earlier commit, I added a bounds check to prevent an out of bounds read and a WARN(). On further discussion and consideration that check was probably too aggressive. Instead of returning -EINVAL, a better fix would be to just prevent the out of bounds read but continue the process. Background: The value of "pp->rxq_def" is a number between 0-7 by default, or even higher depending on the value of "rxq_number", which is a module parameter. If the value is more than the number of available CPUs then it will trigger the WARN() in cpu_max_bits_warn(). Fixes: e8b4fc13 ("net: mvneta: Prevent out of bounds read in mvneta_config_rss()") Signed-off-by:
Dan Carpenter <error27@gmail.com> Reviewed-by:
-
Zhengchao Shao authored
When tb_ring_alloc_rx() failed in tbnet_open(), ida that allocated in tb_xdomain_alloc_out_hopid() is not released. Add tb_xdomain_release_out_hopid() to the error path to release ida. Fixes: 180b0689 ("thunderbolt: Allow multiple DMA tunnels over a single XDomain connection") Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by:
-
Yanteng Si authored
Translate ../loongarch/booting.rst into Chinese. Suggested-by:
Xiaotian Wu <wuxiaotian@loongson.cn> Signed-off-by:
Yanteng Si <siyanteng@loongson.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
Yanteng Si authored
1, Describe the information passed from BootLoader to kernel. 2, Describe the meaning and values of the kernel image header field. Suggested-by:
-
Huacai Chen authored
In virtual machine (guest mode), the tlbwr instruction can not write the last entry of MTLB, so we need to make it non-present by invtlb and then write it by tlbfill. This also simplify the whole logic. Signed-off-by:
Rui Wang <wangrui@loongson.cn> Signed-off-by:
-
