4.9.307-rc1 review
Greg Kroah-Hartman
maintainercover 4.9.307-rc1 review
This is the start of the stable review cycle for the 4.9.307 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 16 Mar 2022 11:27:22 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.307-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.9.307-rc1
Qu Wenruo <[email protected]>
btrfs: unlock newly allocated extent buffer after error
Russell King (Oracle) <[email protected]>
ARM: fix Thumb2 regression with Spectre BHB
Sven Eckelmann <[email protected]>
batman-adv: Don't expect inter-netns unique iflink indices
Sven Eckelmann <[email protected]>
batman-adv: Request iflink once in batadv-on-batadv check
James Morse <[email protected]>
KVM: arm64: Reset PMC_EL0 to avoid a panic() on systems with no PMU
Dan Carpenter <[email protected]>
staging: gdm724x: fix use after free in gdm_lte_rx()
Randy Dunlap <[email protected]>
ARM: Spectre-BHB: provide empty stub for non-config
Mike Kravetz <[email protected]>
selftests/memfd: clean up mapping in mfd_fail_write
Sven Schnelle <[email protected]>
tracing: Ensure trace buffer is at least 4096 bytes large
Marek Marczykowski-Górecki <[email protected]>
Revert "xen-netback: Check for hotplug-status existence before watching"
suresh kumar <[email protected]>
net-sysfs: add check for netdevice being present to speed_show
Eric Dumazet <[email protected]>
sctp: fix kernel-infoleak for SCTP sockets
Mark Featherston <[email protected]>
gpio: ts4900: Do not set DAT and OE together
Pavel Skripkin <[email protected]>
NFC: port100: fix use-after-free in port100_send_complete
Mohammad Kabat <[email protected]>
net/mlx5: Fix size field in bufferx_reg struct
Duoming Zhou <[email protected]>
ax25: Fix NULL pointer dereference in ax25_kill_by_device
Jiasheng Jiang <[email protected]>
net: ethernet: lpc_eth: Handle error for clk_enable
Miaoqian Lin <[email protected]>
ethernet: Fix error handling in xemaclite_of_probe
Tom Rix <[email protected]>
qed: return status of qed_iov_get_link
Jia-Ju Bai <[email protected]>
net: qlogic: check the return value of dma_alloc_coherent() in qed_vf_hw_prepare()
-------------
Diffstat:
Makefile | 4 ++-- arch/arm/include/asm/spectre.h | 6 ++++++ arch/arm/kernel/entry-armv.S | 4 ++-- arch/arm64/kvm/sys_regs.c | 4 +++- drivers/gpio/gpio-ts4900.c | 24 +++++++++++++++++++----- drivers/net/ethernet/nxp/lpc_eth.c | 5 ++++- drivers/net/ethernet/qlogic/qed/qed_sriov.c | 18 +++++++++++------- drivers/net/ethernet/qlogic/qed/qed_vf.c | 7 +++++++ drivers/net/ethernet/xilinx/xilinx_emaclite.c | 4 +++- drivers/net/xen-netback/xenbus.c | 12 ++++-------- drivers/nfc/port100.c | 2 ++ drivers/staging/gdm724x/gdm_lte.c | 5 +++-- fs/btrfs/extent-tree.c | 1 + include/linux/mlx5/mlx5_ifc.h | 4 ++-- kernel/trace/trace.c | 10 ++++++---- net/ax25/af_ax25.c | 7 +++++++ net/batman-adv/hard-interface.c | 13 ++++++++----- net/core/net-sysfs.c | 2 +- net/sctp/sctp_diag.c | 9 +++------ tools/testing/selftests/memfd/memfd_test.c | 1 + 20 files changed, 95 insertions(+), 47 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/20 net: qlogic: check the return value of dma_alloc_coherent() in qed_vf_hw_prepare()
From: Jia-Ju Bai <[email protected]>
[ Upstream commit e0058f0fa80f6e09c4d363779c241c45a3c56b94 ]
The function dma_alloc_coherent() in qed_vf_hw_prepare() can fail, so its return value should be checked.
--- drivers/net/ethernet/qlogic/qed/qed_vf.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/net/ethernet/qlogic/qed/qed_vf.c +7 -0
@@ -384,6 +384,9 @@ int qed_vf_hw_prepare(struct qed_hwfn *p_hwfn) p_iov->bulletin.size, &p_iov->bulletin.phys, GFP_KERNEL); +if (!p_iov->bulletin.p_virt) + goto free_pf2vf_reply; + DP_VERBOSE(p_hwfn, QED_MSG_IOV, "VF's bulletin Board [%p virt 0x%llx phys 0x%08x bytes]\n", p_iov->bulletin.p_virt,
@@ -397,6 +400,10 @@ int qed_vf_hw_prepare(struct qed_hwfn *p_hwfn)return qed_vf_pf_acquire (p_hwfn); +free_pf2vf_reply: +dma_free_coherent (&p_hwfn->cdev->pdev->dev, +sizeof (union pfvf_tlvs ), + p_iov->pf2vf_reply, p_iov->pf2vf_reply_phys); free_vf2pf_request: dma_free_coherent(&p_hwfn->cdev->pdev->dev, sizeof(union vfpf_tlvs),
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 2/20 qed: return status of qed_iov_get_link
In reply to Greg Kroah-HartmanFrom: Tom Rix <[email protected]>
[ Upstream commit d9dc0c84ad2d4cc911ba252c973d1bf18d5eb9cf ]
Clang static analysis reports this issue
qed_sriov.c:4727:19: warning: Assigned value is
garbage or undefined
ivi->max_tx_rate = tx_rate ? tx_rate : link.speed;
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~link is only sometimes set by the call to qed_iov_get_link() qed_iov_get_link fails without setting link or returning status. So change the decl to return status.
--- drivers/net/ethernet/qlogic/qed/qed_sriov.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-)
drivers/net/ethernet/qlogic/qed/qed_sriov.c +11 -7
@@ -2899,11 +2899,11 @@ int qed_iov_mark_vf_flr(struct qed_hwfn *p_hwfn, u32 *p_disabled_vfs)return found; } -static void qed_iov_get_link (struct qed_hwfn *p_hwfn, -u16 vfid, -struct qed_mcp_link_params *p_params, -struct qed_mcp_link_state *p_link, -struct qed_mcp_link_capabilities *p_caps) +static int qed_iov_get_link (struct qed_hwfn *p_hwfn, +u16 vfid, +struct qed_mcp_link_params *p_params, +struct qed_mcp_link_state *p_link, +struct qed_mcp_link_capabilities *p_caps) { struct qed_vf_info *p_vf = qed_iov_get_vf_info(p_hwfn, vfid,
@@ -2911,7 +2911,7 @@ static void qed_iov_get_link(struct qed_hwfn *p_hwfn,struct qed_bulletin_content *p_bulletin;if (!p_vf) -return ; +return -EINVAL ; p_bulletin = p_vf->bulletin.p_virt;
@@ -2921,6 +2921,7 @@ static void qed_iov_get_link(struct qed_hwfn *p_hwfn,__qed_vf_get_link_state (p_hwfn, p_link, p_bulletin);if (p_caps)__qed_vf_get_link_caps (p_hwfn, p_caps, p_bulletin); +return 0 ; } static void qed_iov_process_mbx_req(struct qed_hwfn *p_hwfn,
@@ -3538,6 +3539,7 @@ static int qed_get_vf_config(struct qed_dev *cdev,struct qed_public_vf_info *vf_info;struct qed_mcp_link_state link;u32 tx_rate; +int ret;/* Sanitize request */ if (IS_VF (cdev))
@@ -3551,7 +3553,9 @@ static int qed_get_vf_config(struct qed_dev *cdev, vf_info =qed_iov_get_public_vf_info (hwfn, vf_id, true); -qed_iov_get_link (hwfn, vf_id,NULL , &link,NULL ); + ret =qed_iov_get_link (hwfn, vf_id,NULL , &link,NULL ); +if (ret) +return ret;/* Fill information about VF */ ivi->vf = vf_id;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 3/20 ethernet: Fix error handling in xemaclite_of_probe
In reply to Greg Kroah-HartmanFrom: Miaoqian Lin <[email protected]>
[ Upstream commit b19ab4b38b06aae12442b2de95ccf58b5dc53584 ]
This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak. As the remove function do.
--- drivers/net/ethernet/xilinx/xilinx_emaclite.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/ethernet/xilinx/xilinx_emaclite.c +3 -1
@@ -1175,7 +1175,7 @@ static int xemaclite_of_probe(struct platform_device *ofdev)if (rc) {dev_err (dev,"Cannot register network device, aborting\n" ); - goto error; + goto put_node; } dev_info(dev,
@@ -1183,6 +1183,8 @@ static int xemaclite_of_probe(struct platform_device *ofdev) (unsigned int __force)ndev->mem_start, lp->base_addr, ndev->irq);return 0 ; +put_node: +of_node_put (lp->phy_node); error:xemaclite_remove_ndev (ndev);return rc;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 4/20 net: ethernet: lpc_eth: Handle error for clk_enable
In reply to Greg Kroah-HartmanFrom: Jiasheng Jiang <[email protected]>
[ Upstream commit 2169b79258c8be803d2595d6456b1e77129fe154 ]
As the potential failure of the clk_enable(), it should be better to check it and return error if fails.
--- drivers/net/ethernet/nxp/lpc_eth.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/ethernet/nxp/lpc_eth.c +4 -1
@@ -1515,6 +1515,7 @@ static int lpc_eth_drv_resume(struct platform_device *pdev) {struct net_device *ndev =platform_get_drvdata (pdev);struct netdata_local *pldat; +int ret;if (device_may_wakeup (&pdev->dev))disable_irq_wake (ndev->irq);
@@ -1524,7 +1525,9 @@ static int lpc_eth_drv_resume(struct platform_device *pdev) pldat =netdev_priv (ndev);/* Enable interface clock */ -clk_enable (pldat->clk); + ret =clk_enable (pldat->clk); +if (ret) +return ret;/* Reset and initialize */ __lpc_eth_reset (pldat);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 5/20 ax25: Fix NULL pointer dereference in ax25_kill_by_device
In reply to Greg Kroah-HartmanFrom: Duoming Zhou <[email protected]>
[ Upstream commit 71171ac8eb34ce7fe6b3267dce27c313ab3cb3ac ]
When two ax25 devices attempted to establish connection, the requester use ax25_create(), ax25_bind() and ax25_connect() to initiate connection. The receiver use ax25_rcv() to accept connection and use ax25_create_cb() in ax25_rcv() to create ax25_cb, but the ax25_cb->sk is NULL. When the receiver is detaching, a NULL pointer dereference bug caused by sock_hold(sk) in ax25_kill_by_device() will happen. The corresponding fail log is shown below:
===============================================================
BUG: KASAN: null-ptr-deref in ax25_device_event+0xfd/0x290 Call Trace: ... ax25_device_event+0xfd/0x290 raw_notifier_call_chain+0x5e/0x70 dev_close_many+0x174/0x220 unregister_netdevice_many+0x1f7/0xa60 unregister_netdevice_queue+0x12f/0x170 unregister_netdev+0x13/0x20 mkiss_close+0xcd/0x140 tty_ldisc_release+0xc0/0x220 tty_release_struct+0x17/0xa0 tty_release+0x62d/0x670
...
This patch add condition check in ax25_kill_by_device(). If s->sk is NULL, it will goto if branch to kill device.
--- net/ax25/af_ax25.c | 7 +++++++ 1 file changed, 7 insertions(+)
net/ax25/af_ax25.c +7 -0
@@ -90,6 +90,13 @@ static void ax25_kill_by_device(struct net_device *dev)ax25_for_each (s, &ax25_list) {if (s->ax25_dev == ax25_dev) { sk = s->sk; +if (!sk) { +spin_unlock_bh (&ax25_list_lock); + s->ax25_dev =NULL ; +ax25_disconnect (s,ENETUNREACH ); +spin_lock_bh (&ax25_list_lock); + goto again; + }sock_hold (sk);spin_unlock_bh (&ax25_list_lock);lock_sock (sk);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 6/20 net/mlx5: Fix size field in bufferx_reg struct
In reply to Greg Kroah-HartmanFrom: Mohammad Kabat <[email protected]>
[ Upstream commit ac77998b7ac3044f0509b097da9637184598980d ]
According to HW spec the field "size" should be 16 bits in bufferx register.
--- include/linux/mlx5/mlx5_ifc.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
include/linux/mlx5/mlx5_ifc.h +2 -2
@@ -7327,8 +7327,8 @@ struct mlx5_ifc_bufferx_reg_bits {u8 reserved_at_0[0x6 ];u8 lossy[0x1 ];u8 epsb[0x1 ]; -u8 reserved_at_8[0xc ]; -u8 size[0xc ]; +u8 reserved_at_8[0x8 ]; +u8 size[0x10 ];u8 xoff_threshold[0x10 ];u8 xon_threshold[0x10 ];
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 7/20 NFC: port100: fix use-after-free in port100_send_complete
In reply to Greg Kroah-HartmanFrom: Pavel Skripkin <[email protected]>
[ Upstream commit f80cfe2f26581f188429c12bd937eb905ad3ac7b ]
Syzbot reported UAF in port100_send_complete(). The root case is in missing usb_kill_urb() calls on error handling path of ->probe function.
port100_send_complete() accesses devm allocated memory which will be freed on probe failure. We should kill this urbs before returning an error from probe function to prevent reported use-after-free
Fail log:
BUG: KASAN: use-after-free in port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935 Read of size 1 at addr ffff88801bb59540 by task ksoftirqd/2/26 ... Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935 __usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1670
...
Allocated by task 1255: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:436 [inline] ____kasan_kmalloc mm/kasan/common.c:515 [inline] ____kasan_kmalloc mm/kasan/common.c:474 [inline] __kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524 alloc_dr drivers/base/devres.c:116 [inline] devm_kmalloc+0x96/0x1d0 drivers/base/devres.c:823 devm_kzalloc include/linux/device.h:209 [inline] port100_probe+0x8a/0x1320 drivers/nfc/port100.c:1502 Freed by task 1255: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track+0x21/0x30 mm/kasan/common.c:45 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370 ____kasan_slab_free mm/kasan/common.c:366 [inline] ____kasan_slab_free+0xff/0x140 mm/kasan/common.c:328 kasan_slab_free include/linux/kasan.h:236 [inline] __cache_free mm/slab.c:3437 [inline] kfree+0xf8/0x2b0 mm/slab.c:3794 release_nodes+0x112/0x1a0 drivers/base/devres.c:501 devres_release_all+0x114/0x190 drivers/base/devres.c:530 really_probe+0x626/0xcc0 drivers/base/dd.c:670
--- drivers/nfc/port100.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/nfc/port100.c +2 -0
@@ -1617,7 +1617,9 @@ static int port100_probe(struct usb_interface *interface,nfc_digital_free_device (dev->nfc_digital_dev); error: +usb_kill_urb (dev->in_urb);usb_free_urb (dev->in_urb); +usb_kill_urb (dev->out_urb);usb_free_urb (dev->out_urb);usb_put_dev (dev->udev);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 8/20 gpio: ts4900: Do not set DAT and OE together
In reply to Greg Kroah-HartmanFrom: Mark Featherston <[email protected]>
[ Upstream commit 03fe003547975680fdb9ff5ab0e41cb68276c4f2 ]
This works around an issue with the hardware where both OE and DAT are exposed in the same register. If both are updated simultaneously, the harware makes no guarantees that OE or DAT will actually change in any given order and may result in a glitch of a few ns on a GPIO pin when changing direction and value in a single write.
Setting direction to input now only affects OE bit. Setting direction to output updates DAT first, then OE.
--- drivers/gpio/gpio-ts4900.c | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-)
drivers/gpio/gpio-ts4900.c +19 -5
@@ -1,7 +1,7 @@/* * Digital I/O driver for Technologic Systems I2C FPGA Core * -* Copyright (C) 2015 Technologic Systems +* Copyright (C) 2015, 2018 Technologic Systems * Copyright (C) 2016 Savoir-Faire Linux * * This program is free software; you can redistribute it and/or
@@ -52,19 +52,33 @@ static int ts4900_gpio_direction_input(struct gpio_chip *chip, {struct ts4900_gpio_priv *priv =gpiochip_get_data (chip); -/* -* This will clear the output enable bit, the other bits are -* dontcare when this is cleared +/* Only clear the OE bit here, requires a RMW. Prevents potential issue +* with OE and data getting to the physical pin at different times. */ -return regmap_write (priv->regmap, offset,0 ); +return regmap_update_bits (priv->regmap, offset,TS4900_GPIO_OE ,0 ); }static int ts4900_gpio_direction_output (struct gpio_chip *chip,unsigned int offset,int value) {struct ts4900_gpio_priv *priv =gpiochip_get_data (chip); +unsigned int reg;int ret; +/* If changing from an input to an output, we need to first set the +* proper data bit to what is requested and then set OE bit. This +* prevents a glitch that can occur on the IO line +*/ +regmap_read (priv->regmap, offset, ®); +if (!(reg &TS4900_GPIO_OE )) { +if (value) + reg =TS4900_GPIO_OUT ; +else + reg &= ~TS4900_GPIO_OUT ; + +regmap_write (priv->regmap, offset, reg); + } +if (value) ret =regmap_write (priv->regmap, offset,TS4900_GPIO_OE |TS4900_GPIO_OUT );
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 9/20 sctp: fix kernel-infoleak for SCTP sockets
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
[ Upstream commit 633593a808980f82d251d0ca89730d8bb8b0220c ]
syzbot reported a kernel infoleak [1] of 4 bytes.
After analysis, it turned out r->idiag_expires is not initialized if inet_sctp_diag_fill() calls inet_diag_msg_common_fill()
Make sure to clear idiag_timer/idiag_retrans/idiag_expires and let inet_diag_msg_sctpasoc_fill() fill them again if needed.
[1]
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline] BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 instrument_copy_to_user include/linux/instrumented.h:121 [inline] copyout lib/iov_iter.c:154 [inline] _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 copy_to_iter include/linux/uio.h:162 [inline] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533 skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline] netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] __sys_recvfrom+0x795/0xa10 net/socket.c:2097 __do_sys_recvfrom net/socket.c:2115 [inline] __se_sys_recvfrom net/socket.c:2111 [inline] __x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae
Uninit was created at:
slab_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3247 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1158 [inline] netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248 __netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373 netlink_dump_start include/linux/netlink.h:254 [inline] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343 netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] sock_write_iter+0x594/0x690 net/socket.c:1061 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:924 [inline] do_writev+0x645/0xe00 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae
Bytes 68-71 of 2508 are uninitialized
Memory access of size 2508 starts at ffff888114f9b000 Data copied to user address 00007f7fe09ff2e0
CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
--- net/sctp/sctp_diag.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
net/sctp/sctp_diag.c +3 -6
@@ -45,10 +45,6 @@ static void inet_diag_msg_sctpasoc_fill(struct inet_diag_msg *r, r->idiag_timer =SCTP_EVENT_TIMEOUT_T3_RTX ; r->idiag_retrans = asoc->rtx_data_chunks; r->idiag_expires =jiffies_to_msecs (t3_rtx->expires - jiffies); - }else { - r->idiag_timer =0 ; - r->idiag_retrans =0 ; - r->idiag_expires =0 ; } }
@@ -128,13 +124,14 @@ static int inet_sctp_diag_fill(struct sock *sk, struct sctp_association *asoc, r =nlmsg_data (nlh);BUG_ON (!sk_fullsock (sk)); + r->idiag_timer =0 ; + r->idiag_retrans =0 ; + r->idiag_expires =0 ;if (asoc) {inet_diag_msg_sctpasoc_fill (r, sk, asoc); }else {inet_diag_msg_common_fill (r, sk); r->idiag_state = sk->sk_state; - r->idiag_timer =0 ; - r->idiag_retrans =0 ; }if (inet_diag_msg_attrs_fill (sk, skb, r, ext, user_ns, net_admin))
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 10/20 net-sysfs: add check for netdevice being present to speed_show
In reply to Greg Kroah-HartmanFrom: suresh kumar <[email protected]>
[ Upstream commit 4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624 ]
When bringing down the netdevice or system shutdown, a panic can be triggered while accessing the sysfs path because the device is already removed.
[ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called
[ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called
...
[ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280 crash> bt
...
PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd"
...
#9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
[exception RIP: dma_pool_alloc+0x1ab]
RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046
RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000
RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090
RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00
R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0
R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
#11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
#12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
#13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
#14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
#15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
#16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
#17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
#18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
#19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
#20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
#21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
#22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
#23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
#24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
#25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
#26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92
crash> net_device.state ffff89443b0c0000
state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER)To prevent this scenario, we also make sure that the netdevice is present.
--- net/core/net-sysfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/core/net-sysfs.c +1 -1
@@ -198,7 +198,7 @@ static ssize_t speed_show(struct device *dev,if (!rtnl_trylock ())return restart_syscall (); -if (netif_running (netdev)) { +if (netif_running (netdev) &&netif_device_present (netdev)) {struct ethtool_link_ksettings cmd;if (!__ethtool_get_link_ksettings (netdev, &cmd))
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 11/20 Revert "xen-netback: Check for hotplug-status existence before watching"
In reply to Greg Kroah-HartmanFrom: Marek Marczykowski-Górecki <[email protected]>
[ Upstream commit e8240addd0a3919e0fd7436416afe9aa6429c484 ]
This reverts commit 2afeec08ab5c86ae21952151f726bfe184f6b23d.
The reasoning in the commit was wrong - the code expected to setup the watch even if 'hotplug-status' didn't exist. In fact, it relied on the watch being fired the first time - to check if maybe 'hotplug-status' is already set to 'connected'. Not registering a watch for non-existing path (which is the case if hotplug script hasn't been executed yet), made the backend not waiting for the hotplug script to execute. This in turns, made the netfront think the interface is fully operational, while in fact it was not (the vif interface on xen-netback side might not be configured yet).
This was a workaround for 'hotplug-status' erroneously being removed. But since that is reverted now, the workaround is not necessary either.
More discussion at
https://lore.kernel.org/xen-devel/[email protected]/T/#u
--- drivers/net/xen-netback/xenbus.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-)
drivers/net/xen-netback/xenbus.c +4 -8
@@ -1040,15 +1040,11 @@ static void connect(struct backend_info *be)xenvif_carrier_on (be->vif);unregister_hotplug_status_watch (be); -if (xenbus_exists (XBT_NIL , dev->nodename,"hotplug-status" )) { - err =xenbus_watch_pathfmt (dev, &be->hotplug_status_watch, -NULL , hotplug_status_changed, -"%s/%s" , dev->nodename, -"hotplug-status" ); -if (err) - goto err; + err =xenbus_watch_pathfmt (dev, &be->hotplug_status_watch,NULL , + hotplug_status_changed, +"%s/%s" , dev->nodename,"hotplug-status" ); +if (!err) be->have_hotplug_status_watch =1 ; - }netif_tx_wake_all_queues (be->vif->dev);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 12/20 tracing: Ensure trace buffer is at least 4096 bytes large
In reply to Greg Kroah-HartmanFrom: Sven Schnelle <[email protected]>
[ Upstream commit 7acf3a127bb7c65ff39099afd78960e77b2ca5de ]
Booting the kernel with 'trace_buf_size=1' give a warning at boot during the ftrace selftests:
[ 0.892809] Running postponed tracer tests: [ 0.892893] Testing tracer function: [ 0.901899] Callback from call_rcu_tasks_trace() invoked. [ 0.983829] Callback from call_rcu_tasks_rude() invoked. [ 1.072003] .. bad ring buffer .. corrupted trace buffer .. [ 1.091944] Callback from call_rcu_tasks() invoked. [ 1.097695] PASSED [ 1.097701] Testing dynamic ftrace: .. filter failed count=0 ..FAILED! [ 1.353474] ------------[ cut here ]------------ [ 1.353478] WARNING: CPU: 0 PID: 1 at kernel/trace/trace.c:1951 run_tracer_selftest+0x13c/0x1b0
Therefore enforce a minimum of 4096 bytes to make the selftest pass.
--- kernel/trace/trace.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
kernel/trace/trace.c +6 -4
@@ -1077,10 +1077,12 @@ static int __init set_buf_size(char *str)if (!str)return 0 ; buf_size =memparse (str, &str); -/* nr_entries can not be zero */ -if (buf_size ==0 ) -return 0 ; - trace_buf_size = buf_size; +/* +* nr_entries can not be zero and the startup +* tests require some buffer space. Therefore +* ensure we have at least 4096 bytes of buffer. +*/ + trace_buf_size =max (4096UL , buf_size);return 1 ; }__setup ("trace_buf_size=" , set_buf_size);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 13/20 selftests/memfd: clean up mapping in mfd_fail_write
In reply to Greg Kroah-HartmanFrom: Mike Kravetz <[email protected]>
[ Upstream commit fda153c89af344d21df281009a9d046cf587ea0f ]
Running the memfd script ./run_hugetlbfs_test.sh will often end in error as follows:
memfd-hugetlb: CREATE
memfd-hugetlb: BASIC
memfd-hugetlb: SEAL-WRITE
memfd-hugetlb: SEAL-FUTURE-WRITE
memfd-hugetlb: SEAL-SHRINK fallocate(ALLOC) failed: No space left on device
./run_hugetlbfs_test.sh: line 60: 166855 Aborted (core dumped) ./memfd_test hugetlbfs
opening: ./mnt/memfd
fuse: DONE
If no hugetlb pages have been preallocated, run_hugetlbfs_test.sh will allocate 'just enough' pages to run the test. In the SEAL-FUTURE-WRITE test the mfd_fail_write routine maps the file, but does not unmap. As a result, two hugetlb pages remain reserved for the mapping. When the fallocate call in the SEAL-SHRINK test attempts allocate all hugetlb pages, it is short by the two reserved pages.
Fix by making sure to unmap in mfd_fail_write.
--- tools/testing/selftests/memfd/memfd_test.c | 1 + 1 file changed, 1 insertion(+)
tools/testing/selftests/memfd/memfd_test.c +1 -0
@@ -373,6 +373,7 @@ static void mfd_fail_write(int fd)printf ("mmap()+mprotect() didn't fail as expected\n" );abort (); } +munmap (p, mfd_def_size); }/* verify PUNCH_HOLE fails */
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 14/20 ARM: Spectre-BHB: provide empty stub for non-config
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
commit 68453767131a5deec1e8f9ac92a9042f929e585d upstream.
When CONFIG_GENERIC_CPU_VULNERABILITIES is not set, references to spectre_v2_update_state() cause a build error, so provide an empty stub for that function when the Kconfig option is not set.
Fixes this build error:
arm-linux-gnueabi-ld: arch/arm/mm/proc-v7-bugs.o: in function `cpu_v7_bugs_init':
proc-v7-bugs.c:(.text+0x52): undefined reference to `spectre_v2_update_state'
arm-linux-gnueabi-ld: proc-v7-bugs.c:(.text+0x82): undefined reference to `spectre_v2_update_state'
--- arch/arm/include/asm/spectre.h | 6 ++++++ 1 file changed, 6 insertions(+)
arch/arm/include/asm/spectre.h +6 -0
@@ -25,7 +25,13 @@ enum { SPECTRE_V2_METHOD_LOOP8 = BIT(__SPECTRE_V2_METHOD_LOOP8), }; +#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES void spectre_v2_update_state (unsigned int state,unsigned int methods); +#else +static inline void spectre_v2_update_state (unsigned int state, +unsigned int methods) +{} +#endif int spectre_bhb_update_vectors (unsigned int method);
Greg Kroah-Hartman
maintainerPATCH 15/20 staging: gdm724x: fix use after free in gdm_lte_rx()
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
commit fc7f750dc9d102c1ed7bbe4591f991e770c99033 upstream.
The netif_rx_ni() function frees the skb so we can't dereference it to save the skb->len.
--- drivers/staging/gdm724x/gdm_lte.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/staging/gdm724x/gdm_lte.c +3 -2
@@ -85,14 +85,15 @@ static void tx_complete(void *arg)static int gdm_lte_rx (struct sk_buff *skb,struct nic *nic,int nic_type) { -int ret; +int ret, len; + len = skb->len +ETH_HLEN ; ret =netif_rx_ni (skb);if (ret ==NET_RX_DROP ) { nic->stats.rx_dropped++; }else { nic->stats.rx_packets++; - nic->stats.rx_bytes += skb->len +ETH_HLEN ; + nic->stats.rx_bytes += len; }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 16/20 KVM: arm64: Reset PMC_EL0 to avoid a panic() on systems with no PMU
In reply to Greg Kroah-HartmanFrom: James Morse <[email protected]>
The logic in commit 2a5f1b67ec57 "KVM: arm64: Don't access PMCR_EL0 when no PMU is available" relies on an empty reset handler being benign. This was not the case in earlier kernel versions, so the stable backport of this patch is causing problems.
KVMs behaviour in this area changed over time. In particular, prior to commit 03fdfb269009 ("KVM: arm64: Don't write junk to sysregs on reset"), an empty reset handler will trigger a warning, as the guest registers have been poisoned.
Prior to commit 20589c8cc47d ("arm/arm64: KVM: Don't panic on failure to properly reset system registers"), this warning was a panic().
Instead of reverting the backport, make it write 0 to the sys_reg[] array. This keeps the reset logic happy, and the dodgy value can't be seen by the guest as it can't request the emulation.
The original bug was accessing the PMCR_EL0 register on CPUs that don't implement that feature. There is no known silicon that does this, but v4.9's ACPI support is unable to find the PMU, so triggers this code:
| Kernel panic - not syncing: Didn't reset vcpu_sys_reg(24) | CPU: 1 PID: 3055 Comm: lkvm Not tainted 4.9.302-00032-g64e078a56789 #13476 | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Jul 30 2018 | Call trace: | [<ffff00000808b4b0>] dump_backtrace+0x0/0x1a0 | [<ffff00000808b664>] show_stack+0x14/0x20 | [<ffff0000088f0e18>] dump_stack+0x98/0xb8 | [<ffff0000088eef08>] panic+0x118/0x274 | [<ffff0000080b50e0>] access_actlr+0x0/0x20 | [<ffff0000080b2620>] kvm_reset_vcpu+0x5c/0xac | [<ffff0000080ac688>] kvm_arch_vcpu_ioctl+0x3e4/0x490 | [<ffff0000080a382c>] kvm_vcpu_ioctl+0x5b8/0x720 | [<ffff000008201e44>] do_vfs_ioctl+0x2f4/0x884 | [<ffff00000820244c>] SyS_ioctl+0x78/0x9c | [<ffff000008083a9c>] __sys_trace_return+0x0/0x4
--- arch/arm64/kvm/sys_regs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/arm64/kvm/sys_regs.c +3 -1
@@ -451,8 +451,10 @@ static void reset_pmcr(struct kvm_vcpu *u64 pmcr, val;/* No PMU available, PMCR_EL0 may UNDEF... */ -if (!kvm_arm_support_pmu_v3 ()) +if (!kvm_arm_support_pmu_v3 ()) { +vcpu_sys_reg (vcpu,PMCR_EL0 ) =0 ;return ; + } pmcr =read_sysreg (pmcr_el0);/*
Greg Kroah-Hartman
maintainerPATCH 17/20 batman-adv: Request iflink once in batadv-on-batadv check
In reply to Greg Kroah-HartmanFrom: Sven Eckelmann <[email protected]>
commit 690bb6fb64f5dc7437317153902573ecad67593d upstream.
There is no need to call dev_get_iflink multiple times for the same net_device in batadv_is_on_batman_iface. And since some of the .ndo_get_iflink callbacks are dynamic (for example via RCUs like in vxcan_get_iflink), it could easily happen that the returned values are not stable. The pre-checks before __dev_get_by_index are then of course bogus.
--- net/batman-adv/hard-interface.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
net/batman-adv/hard-interface.c +5 -4
@@ -155,22 +155,23 @@ static bool batadv_is_on_batman_iface(costruct net *net =dev_net (net_dev);struct net_device *parent_dev;const struct net *parent_net; +int iflink;bool ret;/* check if this is a batman-adv mesh interface */ if (batadv_softif_is_valid (net_dev))return true; + iflink =dev_get_iflink (net_dev); +/* no more parents..stop recursion */ -if (dev_get_iflink (net_dev) ==0 || -dev_get_iflink (net_dev) == net_dev->ifindex) +if (iflink ==0 || iflink == net_dev->ifindex)return false; parent_net =batadv_getlink_net (net_dev, net);/* recurse over the parent device */ - parent_dev =__dev_get_by_index ((struct net *)parent_net, -dev_get_iflink (net_dev)); + parent_dev =__dev_get_by_index ((struct net *)parent_net, iflink);/* if we got a NULL parent_dev there is something broken.. */ if (!parent_dev) {pr_err ("Cannot find parent device\n" );
Greg Kroah-Hartman
maintainerPATCH 18/20 batman-adv: Dont expect inter-netns unique iflink indices
In reply to Greg Kroah-HartmanFrom: Sven Eckelmann <[email protected]>
commit 6c1f41afc1dbe59d9d3c8bb0d80b749c119aa334 upstream.
The ifindex doesn't have to be unique for multiple network namespaces on the same machine.
$ ip netns add test1 $ ip -net test1 link add dummy1 type dummy $ ip netns add test2 $ ip -net test2 link add dummy2 type dummy
$ ip -net test1 link show dev dummy1
6: dummy1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 96:81:55:1e:dd:85 brd ff:ff:ff:ff:ff:ff
$ ip -net test2 link show dev dummy2
6: dummy2: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 5a:3c:af:35:07:c3 brd ff:ff:ff:ff:ff:ffBut the batman-adv code to walk through the various layers of virtual interfaces uses this assumption because dev_get_iflink handles it internally and doesn't return the actual netns of the iflink. And dev_get_iflink only documents the situation where ifindex == iflink for physical devices.
But only checking for dev->netdev_ops->ndo_get_iflink is also not an option because ipoib_get_iflink implements it even when it sometimes returns an iflink != ifindex and sometimes iflink == ifindex. The caller must therefore make sure itself to check both netns and iflink + ifindex for equality. Only when they are equal, a "physical" interface was detected which should stop the traversal. On the other hand, vxcan_get_iflink can also return 0 in case there was currently no valid peer. In this case, it is still necessary to stop.
--- net/batman-adv/hard-interface.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
net/batman-adv/hard-interface.c +5 -3
@@ -163,13 +163,15 @@ static bool batadv_is_on_batman_iface(coreturn true; iflink =dev_get_iflink (net_dev); - -/* no more parents..stop recursion */ -if (iflink ==0 || iflink == net_dev->ifindex) +if (iflink ==0 )return false; parent_net =batadv_getlink_net (net_dev, net); +/* iflink to itself, most likely physical device */ +if (net == parent_net && iflink == net_dev->ifindex) +return false; +/* recurse over the parent device */ parent_dev =__dev_get_by_index ((struct net *)parent_net, iflink);/* if we got a NULL parent_dev there is something broken.. */
Greg Kroah-Hartman
maintainerPATCH 19/20 ARM: fix Thumb2 regression with Spectre BHB
In reply to Greg Kroah-HartmanFrom: Russell King (Oracle) <[email protected]>
commit 6c7cb60bff7aec24b834343ff433125f469886a3 upstream.
When building for Thumb2, the vectors make use of a local label. Sadly, the Spectre BHB code also uses a local label with the same number which results in the Thumb2 reference pointing at the wrong place. Fix this by changing the number used for the Spectre BHB local label.
--- arch/arm/kernel/entry-armv.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/kernel/entry-armv.S +2 -2
@@ -1074,9 +1074,9 @@ vector_bhb_loop8_\name: @ bhb workaround mov r0, #8 -1: b . + 4 +3: b . + 4 subs r0, r0, #1 - bne 1b + bne 3b dsb isb b 2b
Greg Kroah-Hartman
maintainerPATCH 20/20 btrfs: unlock newly allocated extent buffer after error
In reply to Greg Kroah-HartmanFrom: Qu Wenruo <[email protected]>
commit 19ea40dddf1833db868533958ca066f368862211 upstream.
[BUG]
There is a bug report that injected ENOMEM error could leave a tree block locked while we return to user-space:
BTRFS info (device loop0): enabling ssd optimizations
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 0 PID: 7579 Comm: syz-executor Not tainted 5.15.0-rc1 #16 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106 fail_dump lib/fault-inject.c:52 [inline] should_fail+0x13c/0x160 lib/fault-inject.c:146 should_failslab+0x5/0x10 mm/slab_common.c:1328 slab_pre_alloc_hook.constprop.99+0x4e/0xc0 mm/slab.h:494 slab_alloc_node mm/slub.c:3120 [inline] slab_alloc mm/slub.c:3214 [inline] kmem_cache_alloc+0x44/0x280 mm/slub.c:3219 btrfs_alloc_delayed_extent_op fs/btrfs/delayed-ref.h:299 [inline] btrfs_alloc_tree_block+0x38c/0x670 fs/btrfs/extent-tree.c:4833 __btrfs_cow_block+0x16f/0x7d0 fs/btrfs/ctree.c:415 btrfs_cow_block+0x12a/0x300 fs/btrfs/ctree.c:570 btrfs_search_slot+0x6b0/0xee0 fs/btrfs/ctree.c:1768 btrfs_insert_empty_items+0x80/0xf0 fs/btrfs/ctree.c:3905 btrfs_new_inode+0x311/0xa60 fs/btrfs/inode.c:6530 btrfs_create+0x12b/0x270 fs/btrfs/inode.c:6783 lookup_open+0x660/0x780 fs/namei.c:3282 open_last_lookups fs/namei.c:3352 [inline] path_openat+0x465/0xe20 fs/namei.c:3557 do_filp_open+0xe3/0x170 fs/namei.c:3588 do_sys_openat2+0x357/0x4a0 fs/open.c:1200 do_sys_open+0x87/0xd0 fs/open.c:1216 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x34/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x46ae99 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f46711b9c48 EFLAGS: 00000246 ORIG_RAX: 0000000000000055 RAX: ffffffffffffffda RBX: 000000000078c0a0 RCX: 000000000046ae99 RDX: 0000000000000000 RSI: 00000000000000a1 RDI: 0000000020005800 RBP: 00007f46711b9c80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000017 R13: 0000000000000000 R14: 000000000078c0a0 R15: 00007ffc129da6e0
================================================
WARNING: lock held when returning to user space! 5.15.0-rc1 #16 Not tainted
------------------------------------------------
syz-executor/7579 is leaving the kernel with locks still held! 1 lock held by syz-executor/7579:
#0: ffff888104b73da8 (btrfs-tree-01/1){+.+.}-{3:3}, at:
__btrfs_tree_lock+0x2e/0x1a0 fs/btrfs/locking.c:112
[CAUSE]
In btrfs_alloc_tree_block(), after btrfs_init_new_buffer(), the new extent buffer @buf is locked, but if later operations like adding delayed tree ref fail, we just free @buf without unlocking it, resulting above warning.
[FIX]
Unlock @buf in out_free_buf: label.
--- fs/btrfs/extent-tree.c | 1 + 1 file changed, 1 insertion(+)
fs/btrfs/extent-tree.c +1 -0
@@ -8457,6 +8457,7 @@ struct extent_buffer *btrfs_alloc_tree_b out_free_delayed:btrfs_free_delayed_extent_op (extent_op); out_free_buf: +btrfs_tree_unlock (buf);free_extent_buffer (buf); out_free_reserved:btrfs_free_reserved_extent (root, ins.objectid, ins.offset,0 );