* [PATCH 5.4 01/74] RDMA/cma: Use output interface for net_dev check
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 02/74] IB/hfi1: Correctly move list in sc_disable() Greg Kroah-Hartman
` (79 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Håkon Bugge, Leon Romanovsky,
Leon Romanovsky, Sasha Levin
From: Håkon Bugge <haakon.bugge@oracle.com>
[ Upstream commit eb83f502adb036cd56c27e13b9ca3b2aabfa790b ]
Commit 27cfde795a96 ("RDMA/cma: Fix arguments order in net device
validation") swapped the src and dst addresses in the call to
validate_net_dev().
As a consequence, the test in validate_ipv4_net_dev() to see if the
net_dev is the right one, is incorrect for port 1 <-> 2 communication when
the ports are on the same sub-net. This is fixed by denoting the
flowi4_oif as the device instead of the incoming one.
The bug has not been observed using IPv6 addresses.
Fixes: 27cfde795a96 ("RDMA/cma: Fix arguments order in net device validation")
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Link: https://lore.kernel.org/r/20221012141542.16925-1-haakon.bugge@oracle.com
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/core/cma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index cf174aa7fe25..052d15629153 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -1434,7 +1434,7 @@ static bool validate_ipv4_net_dev(struct net_device *net_dev,
return false;
memset(&fl4, 0, sizeof(fl4));
- fl4.flowi4_iif = net_dev->ifindex;
+ fl4.flowi4_oif = net_dev->ifindex;
fl4.daddr = daddr;
fl4.saddr = saddr;
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 02/74] IB/hfi1: Correctly move list in sc_disable()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 01/74] RDMA/cma: Use output interface for net_dev check Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 03/74] NFSv4.1: Handle RECLAIM_COMPLETE trunking errors Greg Kroah-Hartman
` (78 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Dean Luick, Dennis Dalessandro,
Leon Romanovsky, Sasha Levin
From: Dean Luick <dean.luick@cornelisnetworks.com>
[ Upstream commit 1afac08b39d85437187bb2a92d89a741b1078f55 ]
Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()")
incorrectly tries to move a list from one list head to another. The
result is a kernel crash.
The crash is triggered when a link goes down and there are waiters for a
send to complete. The following signature is seen:
BUG: kernel NULL pointer dereference, address: 0000000000000030
[...]
Call Trace:
sc_disable+0x1ba/0x240 [hfi1]
pio_freeze+0x3d/0x60 [hfi1]
handle_freeze+0x27/0x1b0 [hfi1]
process_one_work+0x1b0/0x380
? process_one_work+0x380/0x380
worker_thread+0x30/0x360
? process_one_work+0x380/0x380
kthread+0xd7/0x100
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x1f/0x30
The fix is to use the correct call to move the list.
Fixes: 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()")
Signed-off-by: Dean Luick <dean.luick@cornelisnetworks.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
Link: https://lore.kernel.org/r/166610327042.674422.6146908799669288976.stgit@awfm-02.cornelisnetworks.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/hw/hfi1/pio.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1/pio.c b/drivers/infiniband/hw/hfi1/pio.c
index 1a82ea73a0fc..fa5de362010f 100644
--- a/drivers/infiniband/hw/hfi1/pio.c
+++ b/drivers/infiniband/hw/hfi1/pio.c
@@ -955,8 +955,7 @@ void sc_disable(struct send_context *sc)
spin_unlock(&sc->release_lock);
write_seqlock(&sc->waitlock);
- if (!list_empty(&sc->piowait))
- list_move(&sc->piowait, &wake_list);
+ list_splice_init(&sc->piowait, &wake_list);
write_sequnlock(&sc->waitlock);
while (!list_empty(&wake_list)) {
struct iowait *wait;
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 03/74] NFSv4.1: Handle RECLAIM_COMPLETE trunking errors
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 01/74] RDMA/cma: Use output interface for net_dev check Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 02/74] IB/hfi1: Correctly move list in sc_disable() Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 04/74] NFSv4.1: We must always send RECLAIM_COMPLETE after a reboot Greg Kroah-Hartman
` (77 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Trond Myklebust, Anna Schumaker,
Sasha Levin
From: Trond Myklebust <trond.myklebust@hammerspace.com>
[ Upstream commit 5d917cba3201e5c25059df96c29252fd99c4f6a7 ]
If RECLAIM_COMPLETE sets the NFS4CLNT_BIND_CONN_TO_SESSION flag, then we
need to loop back in order to handle it.
Fixes: 0048fdd06614 ("NFSv4.1: RECLAIM_COMPLETE must handle NFS4ERR_CONN_NOT_BOUND_TO_SESSION")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/nfs/nfs4state.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index 1d2b81a233bb..700cb36c93f3 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -2588,6 +2588,7 @@ static void nfs4_state_manager(struct nfs_client *clp)
if (status < 0)
goto out_error;
nfs4_state_end_reclaim_reboot(clp);
+ continue;
}
/* Detect expired delegations... */
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 04/74] NFSv4.1: We must always send RECLAIM_COMPLETE after a reboot
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 03/74] NFSv4.1: Handle RECLAIM_COMPLETE trunking errors Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 05/74] nfs4: Fix kmemleak when allocate slot failed Greg Kroah-Hartman
` (76 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Trond Myklebust, Anna Schumaker,
Sasha Levin
From: Trond Myklebust <trond.myklebust@hammerspace.com>
[ Upstream commit e59679f2b7e522ecad99974e5636291ffd47c184 ]
Currently, we are only guaranteed to send RECLAIM_COMPLETE if we have
open state to recover. Fix the client to always send RECLAIM_COMPLETE
after setting up the lease.
Fixes: fce5c838e133 ("nfs41: RECLAIM_COMPLETE functionality")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/nfs/nfs4state.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index 700cb36c93f3..c60b3a1f6d2b 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -1743,6 +1743,7 @@ static void nfs4_state_mark_reclaim_helper(struct nfs_client *clp,
static void nfs4_state_start_reclaim_reboot(struct nfs_client *clp)
{
+ set_bit(NFS4CLNT_RECLAIM_REBOOT, &clp->cl_state);
/* Mark all delegations for reclaim */
nfs_delegation_mark_reclaim(clp);
nfs4_state_mark_reclaim_helper(clp, nfs4_state_mark_reclaim_reboot);
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 05/74] nfs4: Fix kmemleak when allocate slot failed
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 04/74] NFSv4.1: We must always send RECLAIM_COMPLETE after a reboot Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 06/74] net: dsa: Fix possible memory leaks in dsa_loop_init() Greg Kroah-Hartman
` (75 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Zhang Xiaoxu, Anna Schumaker, Sasha Levin
From: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
[ Upstream commit 7e8436728e22181c3f12a5dbabd35ed3a8b8c593 ]
If one of the slot allocate failed, should cleanup all the other
allocated slots, otherwise, the allocated slots will leak:
unreferenced object 0xffff8881115aa100 (size 64):
comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s)
hex dump (first 32 bytes):
00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130
[<000000005472a39c>] nfs4_realloc_slot_table+0x23f/0x270
[<00000000cd8ca0eb>] nfs40_init_client+0x4a/0x90
[<00000000128486db>] nfs4_init_client+0xce/0x270
[<000000008d2cacad>] nfs4_set_client+0x1a2/0x2b0
[<000000000e593b52>] nfs4_create_server+0x300/0x5f0
[<00000000e4425dd2>] nfs4_try_get_tree+0x65/0x110
[<00000000d3a6176f>] vfs_get_tree+0x41/0xf0
[<0000000016b5ad4c>] path_mount+0x9b3/0xdd0
[<00000000494cae71>] __x64_sys_mount+0x190/0x1d0
[<000000005d56bdec>] do_syscall_64+0x35/0x80
[<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Fixes: abf79bb341bf ("NFS: Add a slot table to struct nfs_client for NFSv4.0 transport blocking")
Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/nfs/nfs4client.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
index 3671a51fe5eb..1f4bdcda3fda 100644
--- a/fs/nfs/nfs4client.c
+++ b/fs/nfs/nfs4client.c
@@ -346,6 +346,7 @@ int nfs40_init_client(struct nfs_client *clp)
ret = nfs4_setup_slot_table(tbl, NFS4_MAX_SLOT_TABLE,
"NFSv4.0 transport Slot table");
if (ret) {
+ nfs4_shutdown_slot_table(tbl);
kfree(tbl);
return ret;
}
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 06/74] net: dsa: Fix possible memory leaks in dsa_loop_init()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 05/74] nfs4: Fix kmemleak when allocate slot failed Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 07/74] RDMA/core: Fix null-ptr-deref in ib_core_cleanup() Greg Kroah-Hartman
` (74 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Chen Zhongjin, David S. Miller, Sasha Levin
From: Chen Zhongjin <chenzhongjin@huawei.com>
[ Upstream commit 633efc8b3dc96f56f5a57f2a49764853a2fa3f50 ]
kmemleak reported memory leaks in dsa_loop_init():
kmemleak: 12 new suspected memory leaks
unreferenced object 0xffff8880138ce000 (size 2048):
comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s)
backtrace:
[<000000006a94f1d5>] kmalloc_trace+0x26/0x60
[<00000000a9c44622>] phy_device_create+0x5d/0x970
[<00000000d0ee2afc>] get_phy_device+0xf3/0x2b0
[<00000000dca0c71f>] __fixed_phy_register.part.0+0x92/0x4e0
[<000000008a834798>] fixed_phy_register+0x84/0xb0
[<0000000055223fcb>] dsa_loop_init+0xa9/0x116 [dsa_loop]
...
There are two reasons for memleak in dsa_loop_init().
First, fixed_phy_register() create and register phy_device:
fixed_phy_register()
get_phy_device()
phy_device_create() # freed by phy_device_free()
phy_device_register() # freed by phy_device_remove()
But fixed_phy_unregister() only calls phy_device_remove().
So the memory allocated in phy_device_create() is leaked.
Second, when mdio_driver_register() fail in dsa_loop_init(),
it just returns and there is no cleanup for phydevs.
Fix the problems by catching the error of mdio_driver_register()
in dsa_loop_init(), then calling both fixed_phy_unregister() and
phy_device_free() to release phydevs.
Also add a function for phydevs cleanup to avoid duplacate.
Fixes: 98cd1552ea27 ("net: dsa: Mock-up driver")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/dsa/dsa_loop.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c
index 0df6c2b9484a..e99e38c6738e 100644
--- a/drivers/net/dsa/dsa_loop.c
+++ b/drivers/net/dsa/dsa_loop.c
@@ -329,6 +329,17 @@ static struct mdio_driver dsa_loop_drv = {
#define NUM_FIXED_PHYS (DSA_LOOP_NUM_PORTS - 2)
+static void dsa_loop_phydevs_unregister(void)
+{
+ unsigned int i;
+
+ for (i = 0; i < NUM_FIXED_PHYS; i++)
+ if (!IS_ERR(phydevs[i])) {
+ fixed_phy_unregister(phydevs[i]);
+ phy_device_free(phydevs[i]);
+ }
+}
+
static int __init dsa_loop_init(void)
{
struct fixed_phy_status status = {
@@ -336,23 +347,23 @@ static int __init dsa_loop_init(void)
.speed = SPEED_100,
.duplex = DUPLEX_FULL,
};
- unsigned int i;
+ unsigned int i, ret;
for (i = 0; i < NUM_FIXED_PHYS; i++)
phydevs[i] = fixed_phy_register(PHY_POLL, &status, NULL);
- return mdio_driver_register(&dsa_loop_drv);
+ ret = mdio_driver_register(&dsa_loop_drv);
+ if (ret)
+ dsa_loop_phydevs_unregister();
+
+ return ret;
}
module_init(dsa_loop_init);
static void __exit dsa_loop_exit(void)
{
- unsigned int i;
-
mdio_driver_unregister(&dsa_loop_drv);
- for (i = 0; i < NUM_FIXED_PHYS; i++)
- if (!IS_ERR(phydevs[i]))
- fixed_phy_unregister(phydevs[i]);
+ dsa_loop_phydevs_unregister();
}
module_exit(dsa_loop_exit);
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 07/74] RDMA/core: Fix null-ptr-deref in ib_core_cleanup()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 06/74] net: dsa: Fix possible memory leaks in dsa_loop_init() Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 08/74] RDMA/qedr: clean up work queue on failure in qedr_alloc_resources() Greg Kroah-Hartman
` (73 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Chen Zhongjin, Leon Romanovsky,
Jason Gunthorpe, Sasha Levin
From: Chen Zhongjin <chenzhongjin@huawei.com>
[ Upstream commit 07c0d131cc0fe1f3981a42958fc52d573d303d89 ]
KASAN reported a null-ptr-deref error:
KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]
CPU: 1 PID: 379
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:destroy_workqueue+0x2f/0x740
RSP: 0018:ffff888016137df8 EFLAGS: 00000202
...
Call Trace:
ib_core_cleanup+0xa/0xa1 [ib_core]
__do_sys_delete_module.constprop.0+0x34f/0x5b0
do_syscall_64+0x3a/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fa1a0d221b7
...
It is because the fail of roce_gid_mgmt_init() is ignored:
ib_core_init()
roce_gid_mgmt_init()
gid_cache_wq = alloc_ordered_workqueue # fail
...
ib_core_cleanup()
roce_gid_mgmt_cleanup()
destroy_workqueue(gid_cache_wq)
# destroy an unallocated wq
Fix this by catching the fail of roce_gid_mgmt_init() in ib_core_init().
Fixes: 03db3a2d81e6 ("IB/core: Add RoCE GID table management")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Link: https://lore.kernel.org/r/20221025024146.109137-1-chenzhongjin@huawei.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/core/device.c | 10 +++++++++-
drivers/infiniband/core/nldev.c | 2 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
index de66d7da1bf6..372ca5347d3c 100644
--- a/drivers/infiniband/core/device.c
+++ b/drivers/infiniband/core/device.c
@@ -2762,10 +2762,18 @@ static int __init ib_core_init(void)
nldev_init();
rdma_nl_register(RDMA_NL_LS, ibnl_ls_cb_table);
- roce_gid_mgmt_init();
+ ret = roce_gid_mgmt_init();
+ if (ret) {
+ pr_warn("Couldn't init RoCE GID management\n");
+ goto err_parent;
+ }
return 0;
+err_parent:
+ rdma_nl_unregister(RDMA_NL_LS);
+ nldev_exit();
+ unregister_pernet_device(&rdma_dev_net_ops);
err_compat:
unregister_blocking_lsm_notifier(&ibdev_lsm_nb);
err_sa:
diff --git a/drivers/infiniband/core/nldev.c b/drivers/infiniband/core/nldev.c
index e4905d9fecb0..81b70f1f1290 100644
--- a/drivers/infiniband/core/nldev.c
+++ b/drivers/infiniband/core/nldev.c
@@ -2098,7 +2098,7 @@ void __init nldev_init(void)
rdma_nl_register(RDMA_NL_NLDEV, nldev_cb_table);
}
-void __exit nldev_exit(void)
+void nldev_exit(void)
{
rdma_nl_unregister(RDMA_NL_NLDEV);
}
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 08/74] RDMA/qedr: clean up work queue on failure in qedr_alloc_resources()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 07/74] RDMA/core: Fix null-ptr-deref in ib_core_cleanup() Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 09/74] nfc: s3fwrn5: Fix potential memory leak in s3fwrn5_nci_send() Greg Kroah-Hartman
` (72 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Dan Carpenter, Leon Romanovsky,
Jason Gunthorpe, Sasha Levin
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit 7a47e077e503feb73d56e491ce89aa73b67a3972 ]
Add a check for if create_singlethread_workqueue() fails and also destroy
the work queue on failure paths.
Fixes: e411e0587e0d ("RDMA/qedr: Add iWARP connection management functions")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/Y1gBkDucQhhWj5YM@kili
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/hw/qedr/main.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/qedr/main.c b/drivers/infiniband/hw/qedr/main.c
index 93040c994e2e..50b75bd4633c 100644
--- a/drivers/infiniband/hw/qedr/main.c
+++ b/drivers/infiniband/hw/qedr/main.c
@@ -362,6 +362,10 @@ static int qedr_alloc_resources(struct qedr_dev *dev)
if (IS_IWARP(dev)) {
xa_init(&dev->qps);
dev->iwarp_wq = create_singlethread_workqueue("qedr_iwarpq");
+ if (!dev->iwarp_wq) {
+ rc = -ENOMEM;
+ goto err1;
+ }
}
/* Allocate Status blocks for CNQ */
@@ -369,7 +373,7 @@ static int qedr_alloc_resources(struct qedr_dev *dev)
GFP_KERNEL);
if (!dev->sb_array) {
rc = -ENOMEM;
- goto err1;
+ goto err_destroy_wq;
}
dev->cnq_array = kcalloc(dev->num_cnq,
@@ -423,6 +427,9 @@ static int qedr_alloc_resources(struct qedr_dev *dev)
kfree(dev->cnq_array);
err2:
kfree(dev->sb_array);
+err_destroy_wq:
+ if (IS_IWARP(dev))
+ destroy_workqueue(dev->iwarp_wq);
err1:
kfree(dev->sgid_tbl);
return rc;
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 09/74] nfc: s3fwrn5: Fix potential memory leak in s3fwrn5_nci_send()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 08/74] RDMA/qedr: clean up work queue on failure in qedr_alloc_resources() Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 10/74] nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send() Greg Kroah-Hartman
` (71 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Shang XiaoJing, David S. Miller,
Sasha Levin
From: Shang XiaoJing <shangxiaojing@huawei.com>
[ Upstream commit 3a146b7e3099dc7cf3114f627d9b79291e2d2203 ]
s3fwrn5_nci_send() will call s3fwrn5_i2c_write() or s3fwrn82_uart_write(),
and free the skb if write() failed. However, even if the write() run
succeeds, the skb will not be freed in write(). As the result, the skb
will memleak. s3fwrn5_nci_send() should also free the skb when write()
succeeds.
Fixes: c04c674fadeb ("nfc: s3fwrn5: Add driver for Samsung S3FWRN5 NFC Chip")
Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/nfc/s3fwrn5/core.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/nfc/s3fwrn5/core.c b/drivers/nfc/s3fwrn5/core.c
index ba6c486d6465..9b43cd3a45af 100644
--- a/drivers/nfc/s3fwrn5/core.c
+++ b/drivers/nfc/s3fwrn5/core.c
@@ -97,11 +97,15 @@ static int s3fwrn5_nci_send(struct nci_dev *ndev, struct sk_buff *skb)
}
ret = s3fwrn5_write(info, skb);
- if (ret < 0)
+ if (ret < 0) {
kfree_skb(skb);
+ mutex_unlock(&info->mutex);
+ return ret;
+ }
+ consume_skb(skb);
mutex_unlock(&info->mutex);
- return ret;
+ return 0;
}
static int s3fwrn5_nci_post_setup(struct nci_dev *ndev)
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 10/74] nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 09/74] nfc: s3fwrn5: Fix potential memory leak in s3fwrn5_nci_send() Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 11/74] net: fec: fix improper use of NETDEV_TX_BUSY Greg Kroah-Hartman
` (70 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Shang XiaoJing, David S. Miller,
Sasha Levin
From: Shang XiaoJing <shangxiaojing@huawei.com>
[ Upstream commit 93d904a734a74c54d945a9884b4962977f1176cd ]
nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb
should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send()
will only free skb when i2c_master_send() return >=0, which means skb
will memleak when i2c_master_send() failed. Free skb no matter whether
i2c_master_send() succeeds.
Fixes: b5b3e23e4cac ("NFC: nfcmrvl: add i2c driver")
Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/nfc/nfcmrvl/i2c.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/nfc/nfcmrvl/i2c.c b/drivers/nfc/nfcmrvl/i2c.c
index 919b4d2f5d8b..fa6db971bee9 100644
--- a/drivers/nfc/nfcmrvl/i2c.c
+++ b/drivers/nfc/nfcmrvl/i2c.c
@@ -151,10 +151,15 @@ static int nfcmrvl_i2c_nci_send(struct nfcmrvl_private *priv,
ret = -EREMOTEIO;
} else
ret = 0;
+ }
+
+ if (ret) {
kfree_skb(skb);
+ return ret;
}
- return ret;
+ consume_skb(skb);
+ return 0;
}
static void nfcmrvl_i2c_nci_update_config(struct nfcmrvl_private *priv,
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 11/74] net: fec: fix improper use of NETDEV_TX_BUSY
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 10/74] nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send() Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 12/74] ata: pata_legacy: fix pdc20230_set_piomode() Greg Kroah-Hartman
` (69 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Zhang Changzhong, David S. Miller,
Sasha Levin
From: Zhang Changzhong <zhangchangzhong@huawei.com>
[ Upstream commit 06a4df5863f73af193a4ff7abf7cb04058584f06 ]
The ndo_start_xmit() method must not free skb when returning
NETDEV_TX_BUSY, since caller is going to requeue freed skb.
Fix it by returning NETDEV_TX_OK in case of dma_map_single() fails.
Fixes: 79f339125ea3 ("net: fec: Add software TSO support")
Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/freescale/fec_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index a31f891d51fb..e1b8c58c4d6b 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -626,7 +626,7 @@ fec_enet_txq_put_data_tso(struct fec_enet_priv_tx_q *txq, struct sk_buff *skb,
dev_kfree_skb_any(skb);
if (net_ratelimit())
netdev_err(ndev, "Tx DMA memory map failed\n");
- return NETDEV_TX_BUSY;
+ return NETDEV_TX_OK;
}
bdp->cbd_datlen = cpu_to_fec16(size);
@@ -688,7 +688,7 @@ fec_enet_txq_put_hdr_tso(struct fec_enet_priv_tx_q *txq,
dev_kfree_skb_any(skb);
if (net_ratelimit())
netdev_err(ndev, "Tx DMA memory map failed\n");
- return NETDEV_TX_BUSY;
+ return NETDEV_TX_OK;
}
}
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 12/74] ata: pata_legacy: fix pdc20230_set_piomode()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (10 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 11/74] net: fec: fix improper use of NETDEV_TX_BUSY Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 13/74] net: sched: Fix use after free in red_enqueue() Greg Kroah-Hartman
` (68 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Damien Le Moal, Sergey Shtylyov,
Sasha Levin
From: Sergey Shtylyov <s.shtylyov@omp.ru>
[ Upstream commit 171a93182eccd6e6835d2c86b40787f9f832efaa ]
Clang gives a warning when compiling pata_legacy.c with 'make W=1' about
the 'rt' local variable in pdc20230_set_piomode() being set but unused.
Quite obviously, there is an outb() call missing to write back the updated
variable. Moreover, checking the docs by Petr Soucek revealed that bitwise
AND should have been done with a negated timing mask and the master/slave
timing masks were swapped while updating...
Fixes: 669a5db411d8 ("[libata] Add a bunch of PATA drivers.")
Reported-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/ata/pata_legacy.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c
index d91ba47f2fc4..4405d255e3aa 100644
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -278,9 +278,10 @@ static void pdc20230_set_piomode(struct ata_port *ap, struct ata_device *adev)
outb(inb(0x1F4) & 0x07, 0x1F4);
rt = inb(0x1F3);
- rt &= 0x07 << (3 * adev->devno);
+ rt &= ~(0x07 << (3 * !adev->devno));
if (pio)
- rt |= (1 + 3 * pio) << (3 * adev->devno);
+ rt |= (1 + 3 * pio) << (3 * !adev->devno);
+ outb(rt, 0x1F3);
udelay(100);
outb(inb(0x1F2) | 0x01, 0x1F2);
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 13/74] net: sched: Fix use after free in red_enqueue()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (11 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 12/74] ata: pata_legacy: fix pdc20230_set_piomode() Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 14/74] net: tun: fix bugs for oversize packet when napi frags enabled Greg Kroah-Hartman
` (67 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Dan Carpenter, Eric Dumazet,
David S. Miller, Sasha Levin
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit 8bdc2acd420c6f3dd1f1c78750ec989f02a1e2b9 ]
We can't use "skb" again after passing it to qdisc_enqueue(). This is
basically identical to commit 2f09707d0c97 ("sch_sfb: Also store skb
len before calling child enqueue").
Fixes: d7f4f332f082 ("sch_red: update backlog as well")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/sched/sch_red.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/sched/sch_red.c b/net/sched/sch_red.c
index 7741f102be4a..476853ff6989 100644
--- a/net/sched/sch_red.c
+++ b/net/sched/sch_red.c
@@ -59,6 +59,7 @@ static int red_enqueue(struct sk_buff *skb, struct Qdisc *sch,
{
struct red_sched_data *q = qdisc_priv(sch);
struct Qdisc *child = q->qdisc;
+ unsigned int len;
int ret;
q->vars.qavg = red_calc_qavg(&q->parms,
@@ -94,9 +95,10 @@ static int red_enqueue(struct sk_buff *skb, struct Qdisc *sch,
break;
}
+ len = qdisc_pkt_len(skb);
ret = qdisc_enqueue(skb, child, to_free);
if (likely(ret == NET_XMIT_SUCCESS)) {
- qdisc_qstats_backlog_inc(sch, skb);
+ sch->qstats.backlog += len;
sch->q.qlen++;
} else if (net_xmit_drop_count(ret)) {
q->stats.pdrop++;
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 14/74] net: tun: fix bugs for oversize packet when napi frags enabled
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (12 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 13/74] net: sched: Fix use after free in red_enqueue() Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 15/74] netfilter: nf_tables: release flow rule object from commit path Greg Kroah-Hartman
` (66 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Ziyang Xuan, Eric Dumazet,
Jakub Kicinski, Sasha Levin
From: Ziyang Xuan <william.xuanziyang@huawei.com>
[ Upstream commit 363a5328f4b0517e59572118ccfb7c626d81dca9 ]
Recently, we got two syzkaller problems because of oversize packet
when napi frags enabled.
One of the problems is because the first seg size of the iov_iter
from user space is very big, it is 2147479538 which is bigger than
the threshold value for bail out early in __alloc_pages(). And
skb->pfmemalloc is true, __kmalloc_reserve() would use pfmemalloc
reserves without __GFP_NOWARN flag. Thus we got a warning as following:
========================================================
WARNING: CPU: 1 PID: 17965 at mm/page_alloc.c:5295 __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
...
Call trace:
__alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
__alloc_pages_node include/linux/gfp.h:550 [inline]
alloc_pages_node include/linux/gfp.h:564 [inline]
kmalloc_large_node+0x94/0x350 mm/slub.c:4038
__kmalloc_node_track_caller+0x620/0x8e4 mm/slub.c:4545
__kmalloc_reserve.constprop.0+0x1e4/0x2b0 net/core/skbuff.c:151
pskb_expand_head+0x130/0x8b0 net/core/skbuff.c:1654
__skb_grow include/linux/skbuff.h:2779 [inline]
tun_napi_alloc_frags+0x144/0x610 drivers/net/tun.c:1477
tun_get_user+0x31c/0x2010 drivers/net/tun.c:1835
tun_chr_write_iter+0x98/0x100 drivers/net/tun.c:2036
The other problem is because odd IPv6 packets without NEXTHDR_NONE
extension header and have big packet length, it is 2127925 which is
bigger than ETH_MAX_MTU(65535). After ipv6_gso_pull_exthdrs() in
ipv6_gro_receive(), network_header offset and transport_header offset
are all bigger than U16_MAX. That would trigger skb->network_header
and skb->transport_header overflow error, because they are all '__u16'
type. Eventually, it would affect the value for __skb_push(skb, value),
and make it be a big value. After __skb_push() in ipv6_gro_receive(),
skb->data would less than skb->head, an out of bounds memory bug occurred.
That would trigger the problem as following:
==================================================================
BUG: KASAN: use-after-free in eth_type_trans+0x100/0x260
...
Call trace:
dump_backtrace+0xd8/0x130
show_stack+0x1c/0x50
dump_stack_lvl+0x64/0x7c
print_address_description.constprop.0+0xbc/0x2e8
print_report+0x100/0x1e4
kasan_report+0x80/0x120
__asan_load8+0x78/0xa0
eth_type_trans+0x100/0x260
napi_gro_frags+0x164/0x550
tun_get_user+0xda4/0x1270
tun_chr_write_iter+0x74/0x130
do_iter_readv_writev+0x130/0x1ec
do_iter_write+0xbc/0x1e0
vfs_writev+0x13c/0x26c
To fix the problems, restrict the packet size less than
(ETH_MAX_MTU - NET_SKB_PAD - NET_IP_ALIGN) which has considered reserved
skb space in napi_alloc_skb() because transport_header is an offset from
skb->head. Add len check in tun_napi_alloc_frags() simply.
Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver")
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20221029094101.1653855-1-william.xuanziyang@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/tun.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index dd02fcc97277..22a46a1382ba 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1492,7 +1492,8 @@ static struct sk_buff *tun_napi_alloc_frags(struct tun_file *tfile,
int err;
int i;
- if (it->nr_segs > MAX_SKB_FRAGS + 1)
+ if (it->nr_segs > MAX_SKB_FRAGS + 1 ||
+ len > (ETH_MAX_MTU - NET_SKB_PAD - NET_IP_ALIGN))
return ERR_PTR(-EMSGSIZE);
local_bh_disable();
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 15/74] netfilter: nf_tables: release flow rule object from commit path
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (13 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 14/74] net: tun: fix bugs for oversize packet when napi frags enabled Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 16/74] ipvs: use explicitly signed chars Greg Kroah-Hartman
` (65 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, syzbot+8f747f62763bc6c32916,
Pablo Neira Ayuso, Sasha Levin
From: Pablo Neira Ayuso <pablo@netfilter.org>
[ Upstream commit 26b5934ff4194e13196bedcba373cd4915071d0e ]
No need to postpone this to the commit release path, since no packets
are walking over this object, this is accessed from control plane only.
This helped uncovered UAF triggered by races with the netlink notifier.
Fixes: 9dd732e0bdf5 ("netfilter: nf_tables: memleak flow rule from commit path")
Reported-by: syzbot+8f747f62763bc6c32916@syzkaller.appspotmail.com
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/netfilter/nf_tables_api.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index f9cecd30f1ba..140c24f1b6c6 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -6576,9 +6576,6 @@ static void nft_commit_release(struct nft_trans *trans)
nf_tables_chain_destroy(&trans->ctx);
break;
case NFT_MSG_DELRULE:
- if (trans->ctx.chain->flags & NFT_CHAIN_HW_OFFLOAD)
- nft_flow_rule_destroy(nft_trans_flow_rule(trans));
-
nf_tables_rule_destroy(&trans->ctx, nft_trans_rule(trans));
break;
case NFT_MSG_DELSET:
@@ -6913,6 +6910,9 @@ static int nf_tables_commit(struct net *net, struct sk_buff *skb)
nft_rule_expr_deactivate(&trans->ctx,
nft_trans_rule(trans),
NFT_TRANS_COMMIT);
+
+ if (trans->ctx.chain->flags & NFT_CHAIN_HW_OFFLOAD)
+ nft_flow_rule_destroy(nft_trans_flow_rule(trans));
break;
case NFT_MSG_NEWSET:
nft_clear(net, nft_trans_set(trans));
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 16/74] ipvs: use explicitly signed chars
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (14 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 15/74] netfilter: nf_tables: release flow rule object from commit path Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 17/74] ipvs: fix WARNING in __ip_vs_cleanup_batch() Greg Kroah-Hartman
` (64 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Jason A. Donenfeld,
Julian Anastasov, Pablo Neira Ayuso, Sasha Levin
From: Jason A. Donenfeld <Jason@zx2c4.com>
[ Upstream commit 5c26159c97b324dc5174a5713eafb8c855cf8106 ]
The `char` type with no explicit sign is sometimes signed and sometimes
unsigned. This code will break on platforms such as arm, where char is
unsigned. So mark it here as explicitly signed, so that the
todrop_counter decrement and subsequent comparison is correct.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/netfilter/ipvs/ip_vs_conn.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
index a189079a6ea5..e913ab0096cb 100644
--- a/net/netfilter/ipvs/ip_vs_conn.c
+++ b/net/netfilter/ipvs/ip_vs_conn.c
@@ -1225,8 +1225,8 @@ static inline int todrop_entry(struct ip_vs_conn *cp)
* The drop rate array needs tuning for real environments.
* Called from timer bh only => no locking
*/
- static const char todrop_rate[9] = {0, 1, 2, 3, 4, 5, 6, 7, 8};
- static char todrop_counter[9] = {0};
+ static const signed char todrop_rate[9] = {0, 1, 2, 3, 4, 5, 6, 7, 8};
+ static signed char todrop_counter[9] = {0};
int i;
/* if the conn entry hasn't lasted for 60 seconds, don't drop it.
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 17/74] ipvs: fix WARNING in __ip_vs_cleanup_batch()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (15 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 16/74] ipvs: use explicitly signed chars Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 18/74] ipvs: fix WARNING in ip_vs_app_net_cleanup() Greg Kroah-Hartman
` (63 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Zhengchao Shao, Julian Anastasov,
Pablo Neira Ayuso, Sasha Levin
From: Zhengchao Shao <shaozhengchao@huawei.com>
[ Upstream commit 3d00c6a0da8ddcf75213e004765e4a42acc71d5d ]
During the initialization of ip_vs_conn_net_init(), if file ip_vs_conn
or ip_vs_conn_sync fails to be created, the initialization is successful
by default. Therefore, the ip_vs_conn or ip_vs_conn_sync file doesn't
be found during the remove.
The following is the stack information:
name 'ip_vs_conn_sync'
WARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712
remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
Call Trace:
<TASK>
__ip_vs_cleanup_batch+0x7d/0x120
ops_exit_list+0x125/0x170
cleanup_net+0x4ea/0xb00
process_one_work+0x9bf/0x1710
worker_thread+0x665/0x1080
kthread+0x2e4/0x3a0
ret_from_fork+0x1f/0x30
</TASK>
Fixes: 61b1ab4583e2 ("IPVS: netns, add basic init per netns.")
Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/netfilter/ipvs/ip_vs_conn.c | 26 +++++++++++++++++++++-----
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
index e913ab0096cb..d66548d2e5de 100644
--- a/net/netfilter/ipvs/ip_vs_conn.c
+++ b/net/netfilter/ipvs/ip_vs_conn.c
@@ -1373,20 +1373,36 @@ int __net_init ip_vs_conn_net_init(struct netns_ipvs *ipvs)
{
atomic_set(&ipvs->conn_count, 0);
- proc_create_net("ip_vs_conn", 0, ipvs->net->proc_net,
- &ip_vs_conn_seq_ops, sizeof(struct ip_vs_iter_state));
- proc_create_net("ip_vs_conn_sync", 0, ipvs->net->proc_net,
- &ip_vs_conn_sync_seq_ops,
- sizeof(struct ip_vs_iter_state));
+#ifdef CONFIG_PROC_FS
+ if (!proc_create_net("ip_vs_conn", 0, ipvs->net->proc_net,
+ &ip_vs_conn_seq_ops,
+ sizeof(struct ip_vs_iter_state)))
+ goto err_conn;
+
+ if (!proc_create_net("ip_vs_conn_sync", 0, ipvs->net->proc_net,
+ &ip_vs_conn_sync_seq_ops,
+ sizeof(struct ip_vs_iter_state)))
+ goto err_conn_sync;
+#endif
+
return 0;
+
+#ifdef CONFIG_PROC_FS
+err_conn_sync:
+ remove_proc_entry("ip_vs_conn", ipvs->net->proc_net);
+err_conn:
+ return -ENOMEM;
+#endif
}
void __net_exit ip_vs_conn_net_cleanup(struct netns_ipvs *ipvs)
{
/* flush all the connection entries first */
ip_vs_conn_flush(ipvs);
+#ifdef CONFIG_PROC_FS
remove_proc_entry("ip_vs_conn", ipvs->net->proc_net);
remove_proc_entry("ip_vs_conn_sync", ipvs->net->proc_net);
+#endif
}
int __init ip_vs_conn_init(void)
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 18/74] ipvs: fix WARNING in ip_vs_app_net_cleanup()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (16 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 17/74] ipvs: fix WARNING in __ip_vs_cleanup_batch() Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 19/74] rose: Fix NULL pointer dereference in rose_send_frame() Greg Kroah-Hartman
` (62 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Zhengchao Shao, Julian Anastasov,
Pablo Neira Ayuso, Sasha Levin
From: Zhengchao Shao <shaozhengchao@huawei.com>
[ Upstream commit 5663ed63adb9619c98ab7479aa4606fa9b7a548c ]
During the initialization of ip_vs_app_net_init(), if file ip_vs_app
fails to be created, the initialization is successful by default.
Therefore, the ip_vs_app file doesn't be found during the remove in
ip_vs_app_net_cleanup(). It will cause WRNING.
The following is the stack information:
name 'ip_vs_app'
WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
Call Trace:
<TASK>
ops_exit_list+0x125/0x170
cleanup_net+0x4ea/0xb00
process_one_work+0x9bf/0x1710
worker_thread+0x665/0x1080
kthread+0x2e4/0x3a0
ret_from_fork+0x1f/0x30
</TASK>
Fixes: 457c4cbc5a3d ("[NET]: Make /proc/net per network namespace")
Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/netfilter/ipvs/ip_vs_app.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_app.c b/net/netfilter/ipvs/ip_vs_app.c
index f9b16f2b2219..fdacbc3c15be 100644
--- a/net/netfilter/ipvs/ip_vs_app.c
+++ b/net/netfilter/ipvs/ip_vs_app.c
@@ -599,13 +599,19 @@ static const struct seq_operations ip_vs_app_seq_ops = {
int __net_init ip_vs_app_net_init(struct netns_ipvs *ipvs)
{
INIT_LIST_HEAD(&ipvs->app_list);
- proc_create_net("ip_vs_app", 0, ipvs->net->proc_net, &ip_vs_app_seq_ops,
- sizeof(struct seq_net_private));
+#ifdef CONFIG_PROC_FS
+ if (!proc_create_net("ip_vs_app", 0, ipvs->net->proc_net,
+ &ip_vs_app_seq_ops,
+ sizeof(struct seq_net_private)))
+ return -ENOMEM;
+#endif
return 0;
}
void __net_exit ip_vs_app_net_cleanup(struct netns_ipvs *ipvs)
{
unregister_ip_vs_app(ipvs, NULL /* all */);
+#ifdef CONFIG_PROC_FS
remove_proc_entry("ip_vs_app", ipvs->net->proc_net);
+#endif
}
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 19/74] rose: Fix NULL pointer dereference in rose_send_frame()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (17 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 18/74] ipvs: fix WARNING in ip_vs_app_net_cleanup() Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 20/74] mISDN: fix possible memory leak in mISDN_register_device() Greg Kroah-Hartman
` (61 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Zhang Qilong, David S. Miller, Sasha Levin
From: Zhang Qilong <zhangqilong3@huawei.com>
[ Upstream commit e97c089d7a49f67027395ddf70bf327eeac2611e ]
The syzkaller reported an issue:
KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387]
CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: rcu_gp srcu_invoke_callbacks
RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101
Call Trace:
<IRQ>
rose_transmit_clear_request+0x1d5/0x290 net/rose/rose_link.c:255
rose_rx_call_request+0x4c0/0x1bc0 net/rose/af_rose.c:1009
rose_loopback_timer+0x19e/0x590 net/rose/rose_loopback.c:111
call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474
expire_timers kernel/time/timer.c:1519 [inline]
__run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790
__run_timers kernel/time/timer.c:1768 [inline]
run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803
__do_softirq+0x1d0/0x9c8 kernel/softirq.c:571
[...]
</IRQ>
It triggers NULL pointer dereference when 'neigh->dev->dev_addr' is
called in the rose_send_frame(). It's the first occurrence of the
`neigh` is in rose_loopback_timer() as `rose_loopback_neigh', and
the 'dev' in 'rose_loopback_neigh' is initialized sa nullptr.
It had been fixed by commit 3b3fd068c56e3fbea30090859216a368398e39bf
("rose: Fix Null pointer dereference in rose_send_frame()") ever.
But it's introduced by commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8
("rose: check NULL rose_loopback_neigh->loopback") again.
We fix it by add NULL check in rose_transmit_clear_request(). When
the 'dev' in 'neigh' is NULL, we don't reply the request and just
clear it.
syzkaller don't provide repro, and I provide a syz repro like:
r0 = syz_init_net_socket$bt_sco(0x1f, 0x5, 0x2)
ioctl$sock_inet_SIOCSIFFLAGS(r0, 0x8914, &(0x7f0000000180)={'rose0\x00', 0x201})
r1 = syz_init_net_socket$rose(0xb, 0x5, 0x0)
bind$rose(r1, &(0x7f00000000c0)=@full={0xb, @dev, @null, 0x0, [@null, @null, @netrom, @netrom, @default, @null]}, 0x40)
connect$rose(r1, &(0x7f0000000240)=@short={0xb, @dev={0xbb, 0xbb, 0xbb, 0x1, 0x0}, @remote={0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0x1}, 0x1, @netrom={0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x0, 0x0}}, 0x1c)
Fixes: 3c53cd65dece ("rose: check NULL rose_loopback_neigh->loopback")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/rose/rose_link.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c
index f6102e6f5161..730d2205f197 100644
--- a/net/rose/rose_link.c
+++ b/net/rose/rose_link.c
@@ -236,6 +236,9 @@ void rose_transmit_clear_request(struct rose_neigh *neigh, unsigned int lci, uns
unsigned char *dptr;
int len;
+ if (!neigh->dev)
+ return;
+
len = AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + ROSE_MIN_LEN + 3;
if ((skb = alloc_skb(len, GFP_ATOMIC)) == NULL)
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 20/74] mISDN: fix possible memory leak in mISDN_register_device()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (18 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 19/74] rose: Fix NULL pointer dereference in rose_send_frame() Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 21/74] isdn: mISDN: netjet: fix wrong check of device registration Greg Kroah-Hartman
` (60 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Yang Yingliang, David S. Miller,
Sasha Levin
From: Yang Yingliang <yangyingliang@huawei.com>
[ Upstream commit e7d1d4d9ac0dfa40be4c2c8abd0731659869b297 ]
Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's
bus_id string array"), the name of device is allocated dynamically,
add put_device() to give up the reference, so that the name can be
freed in kobject_cleanup() when the refcount is 0.
Set device class before put_device() to avoid null release() function
WARN message in device_release().
Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/isdn/mISDN/core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/isdn/mISDN/core.c b/drivers/isdn/mISDN/core.c
index a41b4b264594..7ea0100f218a 100644
--- a/drivers/isdn/mISDN/core.c
+++ b/drivers/isdn/mISDN/core.c
@@ -233,11 +233,12 @@ mISDN_register_device(struct mISDNdevice *dev,
if (debug & DEBUG_CORE)
printk(KERN_DEBUG "mISDN_register %s %d\n",
dev_name(&dev->dev), dev->id);
+ dev->dev.class = &mISDN_class;
+
err = create_stack(dev);
if (err)
goto error1;
- dev->dev.class = &mISDN_class;
dev->dev.platform_data = dev;
dev->dev.parent = parent;
dev_set_drvdata(&dev->dev, dev);
@@ -249,8 +250,8 @@ mISDN_register_device(struct mISDNdevice *dev,
error3:
delete_stack(dev);
- return err;
error1:
+ put_device(&dev->dev);
return err;
}
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 21/74] isdn: mISDN: netjet: fix wrong check of device registration
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (19 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 20/74] mISDN: fix possible memory leak in mISDN_register_device() Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 22/74] btrfs: fix inode list leak during backref walking at resolve_indirect_refs() Greg Kroah-Hartman
` (59 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Yang Yingliang, David S. Miller,
Sasha Levin
From: Yang Yingliang <yangyingliang@huawei.com>
[ Upstream commit bf00f5426074249058a106a6edbb89e4b25a4d79 ]
The class is set in mISDN_register_device(), but if device_add() returns
error, it will lead to delete a device without added, fix this by using
device_is_registered() to check if the device is registered.
Fixes: a900845e5661 ("mISDN: Add support for Traverse Technologies NETJet PCI cards")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/isdn/hardware/mISDN/netjet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/isdn/hardware/mISDN/netjet.c b/drivers/isdn/hardware/mISDN/netjet.c
index 8299defff55a..6d818d5d1377 100644
--- a/drivers/isdn/hardware/mISDN/netjet.c
+++ b/drivers/isdn/hardware/mISDN/netjet.c
@@ -956,7 +956,7 @@ nj_release(struct tiger_hw *card)
}
if (card->irq > 0)
free_irq(card->irq, card);
- if (card->isac.dch.dev.dev.class)
+ if (device_is_registered(&card->isac.dch.dev.dev))
mISDN_unregister_device(&card->isac.dch.dev);
for (i = 0; i < 2; i++) {
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 22/74] btrfs: fix inode list leak during backref walking at resolve_indirect_refs()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (20 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 21/74] isdn: mISDN: netjet: fix wrong check of device registration Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 23/74] btrfs: fix inode list leak during backref walking at find_parent_nodes() Greg Kroah-Hartman
` (58 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Filipe Manana, David Sterba, Sasha Levin
From: Filipe Manana <fdmanana@suse.com>
[ Upstream commit 5614dc3a47e3310fbc77ea3b67eaadd1c6417bf1 ]
During backref walking, at resolve_indirect_refs(), if we get an error
we jump to the 'out' label and call ulist_free() on the 'parents' ulist,
which frees all the elements in the ulist - however that does not free
any inode lists that may be attached to elements, through the 'aux' field
of a ulist node, so we end up leaking lists if we have any attached to
the unodes.
Fix this by calling free_leaf_list() instead of ulist_free() when we exit
from resolve_indirect_refs(). The static function free_leaf_list() is
moved up for this to be possible and it's slightly simplified by removing
unnecessary code.
Fixes: 3301958b7c1d ("Btrfs: add inodes before dropping the extent lock in find_all_leafs")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/btrfs/backref.c | 36 +++++++++++++++++-------------------
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index 7147bb66a482..4809cc07a885 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -642,6 +642,18 @@ unode_aux_to_inode_list(struct ulist_node *node)
return (struct extent_inode_elem *)(uintptr_t)node->aux;
}
+static void free_leaf_list(struct ulist *ulist)
+{
+ struct ulist_node *node;
+ struct ulist_iterator uiter;
+
+ ULIST_ITER_INIT(&uiter);
+ while ((node = ulist_next(ulist, &uiter)))
+ free_inode_elem_list(unode_aux_to_inode_list(node));
+
+ ulist_free(ulist);
+}
+
/*
* We maintain three separate rbtrees: one for direct refs, one for
* indirect refs which have a key, and one for indirect refs which do not
@@ -756,7 +768,11 @@ static int resolve_indirect_refs(struct btrfs_fs_info *fs_info,
cond_resched();
}
out:
- ulist_free(parents);
+ /*
+ * We may have inode lists attached to refs in the parents ulist, so we
+ * must free them before freeing the ulist and its refs.
+ */
+ free_leaf_list(parents);
return ret;
}
@@ -1408,24 +1424,6 @@ static int find_parent_nodes(struct btrfs_trans_handle *trans,
return ret;
}
-static void free_leaf_list(struct ulist *blocks)
-{
- struct ulist_node *node = NULL;
- struct extent_inode_elem *eie;
- struct ulist_iterator uiter;
-
- ULIST_ITER_INIT(&uiter);
- while ((node = ulist_next(blocks, &uiter))) {
- if (!node->aux)
- continue;
- eie = unode_aux_to_inode_list(node);
- free_inode_elem_list(eie);
- node->aux = 0;
- }
-
- ulist_free(blocks);
-}
-
/*
* Finds all leafs with a reference to the specified combination of bytenr and
* offset. key_list_head will point to a list of corresponding keys (caller must
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 23/74] btrfs: fix inode list leak during backref walking at find_parent_nodes()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (21 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 22/74] btrfs: fix inode list leak during backref walking at resolve_indirect_refs() Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 24/74] btrfs: fix ulist leaks in error paths of qgroup self tests Greg Kroah-Hartman
` (57 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Filipe Manana, David Sterba, Sasha Levin
From: Filipe Manana <fdmanana@suse.com>
[ Upstream commit 92876eec382a0f19f33d09d2c939e9ca49038ae5 ]
During backref walking, at find_parent_nodes(), if we are dealing with a
data extent and we get an error while resolving the indirect backrefs, at
resolve_indirect_refs(), or in the while loop that iterates over the refs
in the direct refs rbtree, we end up leaking the inode lists attached to
the direct refs we have in the direct refs rbtree that were not yet added
to the refs ulist passed as argument to find_parent_nodes(). Since they
were not yet added to the refs ulist and prelim_release() does not free
the lists, on error the caller can only free the lists attached to the
refs that were added to the refs ulist, all the remaining refs get their
inode lists never freed, therefore leaking their memory.
Fix this by having prelim_release() always free any attached inode list
to each ref found in the rbtree, and have find_parent_nodes() set the
ref's inode list to NULL once it transfers ownership of the inode list
to a ref added to the refs ulist passed to find_parent_nodes().
Fixes: 86d5f9944252 ("btrfs: convert prelimary reference tracking to use rbtrees")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/btrfs/backref.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index 4809cc07a885..3cbca2ebdeb0 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -287,8 +287,10 @@ static void prelim_release(struct preftree *preftree)
struct prelim_ref *ref, *next_ref;
rbtree_postorder_for_each_entry_safe(ref, next_ref,
- &preftree->root.rb_root, rbnode)
+ &preftree->root.rb_root, rbnode) {
+ free_inode_elem_list(ref->inode_list);
free_pref(ref);
+ }
preftree->root = RB_ROOT_CACHED;
preftree->count = 0;
@@ -1383,6 +1385,12 @@ static int find_parent_nodes(struct btrfs_trans_handle *trans,
if (ret < 0)
goto out;
ref->inode_list = eie;
+ /*
+ * We transferred the list ownership to the ref,
+ * so set to NULL to avoid a double free in case
+ * an error happens after this.
+ */
+ eie = NULL;
}
ret = ulist_add_merge_ptr(refs, ref->parent,
ref->inode_list,
@@ -1408,6 +1416,14 @@ static int find_parent_nodes(struct btrfs_trans_handle *trans,
eie->next = ref->inode_list;
}
eie = NULL;
+ /*
+ * We have transferred the inode list ownership from
+ * this ref to the ref we added to the 'refs' ulist.
+ * So set this ref's inode list to NULL to avoid
+ * use-after-free when our caller uses it or double
+ * frees in case an error happens before we return.
+ */
+ ref->inode_list = NULL;
}
cond_resched();
}
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 24/74] btrfs: fix ulist leaks in error paths of qgroup self tests
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (22 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 23/74] btrfs: fix inode list leak during backref walking at find_parent_nodes() Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 25/74] Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu Greg Kroah-Hartman
` (56 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Filipe Manana, David Sterba, Sasha Levin
From: Filipe Manana <fdmanana@suse.com>
[ Upstream commit d37de92b38932d40e4a251e876cc388f9aee5f42 ]
In the test_no_shared_qgroup() and test_multiple_refs() qgroup self tests,
if we fail to add the tree ref, remove the extent item or remove the
extent ref, we are returning from the test function without freeing the
"old_roots" ulist that was allocated by the previous calls to
btrfs_find_all_roots(). Fix that by calling ulist_free() before returning.
Fixes: 442244c96332 ("btrfs: qgroup: Switch self test to extent-oriented qgroup mechanism.")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/btrfs/tests/qgroup-tests.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/tests/qgroup-tests.c b/fs/btrfs/tests/qgroup-tests.c
index ac035a6fa003..f312ed5abb19 100644
--- a/fs/btrfs/tests/qgroup-tests.c
+++ b/fs/btrfs/tests/qgroup-tests.c
@@ -237,8 +237,10 @@ static int test_no_shared_qgroup(struct btrfs_root *root,
ret = insert_normal_tree_ref(root, nodesize, nodesize, 0,
BTRFS_FS_TREE_OBJECTID);
- if (ret)
+ if (ret) {
+ ulist_free(old_roots);
return ret;
+ }
ret = btrfs_find_all_roots(&trans, fs_info, nodesize, 0, &new_roots,
false);
@@ -273,8 +275,10 @@ static int test_no_shared_qgroup(struct btrfs_root *root,
}
ret = remove_extent_item(root, nodesize, nodesize);
- if (ret)
+ if (ret) {
+ ulist_free(old_roots);
return -EINVAL;
+ }
ret = btrfs_find_all_roots(&trans, fs_info, nodesize, 0, &new_roots,
false);
@@ -338,8 +342,10 @@ static int test_multiple_refs(struct btrfs_root *root,
ret = insert_normal_tree_ref(root, nodesize, nodesize, 0,
BTRFS_FS_TREE_OBJECTID);
- if (ret)
+ if (ret) {
+ ulist_free(old_roots);
return ret;
+ }
ret = btrfs_find_all_roots(&trans, fs_info, nodesize, 0, &new_roots,
false);
@@ -373,8 +379,10 @@ static int test_multiple_refs(struct btrfs_root *root,
ret = add_tree_ref(root, nodesize, nodesize, 0,
BTRFS_FIRST_FREE_OBJECTID);
- if (ret)
+ if (ret) {
+ ulist_free(old_roots);
return ret;
+ }
ret = btrfs_find_all_roots(&trans, fs_info, nodesize, 0, &new_roots,
false);
@@ -414,8 +422,10 @@ static int test_multiple_refs(struct btrfs_root *root,
ret = remove_extent_ref(root, nodesize, nodesize, 0,
BTRFS_FIRST_FREE_OBJECTID);
- if (ret)
+ if (ret) {
+ ulist_free(old_roots);
return ret;
+ }
ret = btrfs_find_all_roots(&trans, fs_info, nodesize, 0, &new_roots,
false);
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 25/74] Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (23 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 24/74] btrfs: fix ulist leaks in error paths of qgroup self tests Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 26/74] Bluetooth: L2CAP: fix use-after-free in l2cap_conn_del() Greg Kroah-Hartman
` (55 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Maxim Mikityanskiy,
Luiz Augusto von Dentz, Sasha Levin
From: Maxim Mikityanskiy <maxtram95@gmail.com>
[ Upstream commit 3aff8aaca4e36dc8b17eaa011684881a80238966 ]
Fix the race condition between the following two flows that run in
parallel:
1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) ->
__sock_queue_rcv_skb.
2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.
An SKB can be queued by the first flow and immediately dequeued and
freed by the second flow, therefore the callers of l2cap_reassemble_sdu
can't use the SKB after that function returns. However, some places
continue accessing struct l2cap_ctrl that resides in the SKB's CB for a
short time after l2cap_reassemble_sdu returns, leading to a
use-after-free condition (the stack trace is below, line numbers for
kernel 5.19.8).
Fix it by keeping a local copy of struct l2cap_ctrl.
BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169
Workqueue: hci0 hci_rx_work [bluetooth]
Call Trace:
<TASK>
dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))
print_report.cold (mm/kasan/report.c:314 mm/kasan/report.c:429)
? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
kasan_report (mm/kasan/report.c:162 mm/kasan/report.c:493)
? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
l2cap_rx (net/bluetooth/l2cap_core.c:7236 net/bluetooth/l2cap_core.c:7271) bluetooth
ret_from_fork (arch/x86/entry/entry_64.S:306)
</TASK>
Allocated by task 43169:
kasan_save_stack (mm/kasan/common.c:39)
__kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)
kmem_cache_alloc_node (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293)
__alloc_skb (net/core/skbuff.c:414)
l2cap_recv_frag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2cap_core.c:8329) bluetooth
l2cap_recv_acldata (net/bluetooth/l2cap_core.c:8442) bluetooth
hci_rx_work (net/bluetooth/hci_core.c:3642 net/bluetooth/hci_core.c:3832) bluetooth
process_one_work (kernel/workqueue.c:2289)
worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2437)
kthread (kernel/kthread.c:376)
ret_from_fork (arch/x86/entry/entry_64.S:306)
Freed by task 27920:
kasan_save_stack (mm/kasan/common.c:39)
kasan_set_track (mm/kasan/common.c:45)
kasan_set_free_info (mm/kasan/generic.c:372)
____kasan_slab_free (mm/kasan/common.c:368 mm/kasan/common.c:328)
slab_free_freelist_hook (mm/slub.c:1780)
kmem_cache_free (mm/slub.c:3536 mm/slub.c:3553)
skb_free_datagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323)
bt_sock_recvmsg (net/bluetooth/af_bluetooth.c:295) bluetooth
l2cap_sock_recvmsg (net/bluetooth/l2cap_sock.c:1212) bluetooth
sock_read_iter (net/socket.c:1087)
new_sync_read (./include/linux/fs.h:2052 fs/read_write.c:401)
vfs_read (fs/read_write.c:482)
ksys_read (fs/read_write.c:620)
do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
Link: https://lore.kernel.org/linux-bluetooth/CAKErNvoqga1WcmoR3-0875esY6TVWFQDandbVZncSiuGPBQXLA@mail.gmail.com/T/#u
Fixes: d2a7ac5d5d3a ("Bluetooth: Add the ERTM receive state machine")
Fixes: 4b51dae96731 ("Bluetooth: Add streaming mode receive and incoming packet classifier")
Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bluetooth/l2cap_core.c | 48 ++++++++++++++++++++++++++++++++------
1 file changed, 41 insertions(+), 7 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 2d28b4e49b7a..5fa9a4e7d3ee 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -6273,6 +6273,7 @@ static int l2cap_rx_state_recv(struct l2cap_chan *chan,
struct l2cap_ctrl *control,
struct sk_buff *skb, u8 event)
{
+ struct l2cap_ctrl local_control;
int err = 0;
bool skb_in_use = false;
@@ -6297,15 +6298,32 @@ static int l2cap_rx_state_recv(struct l2cap_chan *chan,
chan->buffer_seq = chan->expected_tx_seq;
skb_in_use = true;
+ /* l2cap_reassemble_sdu may free skb, hence invalidate
+ * control, so make a copy in advance to use it after
+ * l2cap_reassemble_sdu returns and to avoid the race
+ * condition, for example:
+ *
+ * The current thread calls:
+ * l2cap_reassemble_sdu
+ * chan->ops->recv == l2cap_sock_recv_cb
+ * __sock_queue_rcv_skb
+ * Another thread calls:
+ * bt_sock_recvmsg
+ * skb_recv_datagram
+ * skb_free_datagram
+ * Then the current thread tries to access control, but
+ * it was freed by skb_free_datagram.
+ */
+ local_control = *control;
err = l2cap_reassemble_sdu(chan, skb, control);
if (err)
break;
- if (control->final) {
+ if (local_control.final) {
if (!test_and_clear_bit(CONN_REJ_ACT,
&chan->conn_state)) {
- control->final = 0;
- l2cap_retransmit_all(chan, control);
+ local_control.final = 0;
+ l2cap_retransmit_all(chan, &local_control);
l2cap_ertm_send(chan);
}
}
@@ -6685,11 +6703,27 @@ static int l2cap_rx(struct l2cap_chan *chan, struct l2cap_ctrl *control,
static int l2cap_stream_rx(struct l2cap_chan *chan, struct l2cap_ctrl *control,
struct sk_buff *skb)
{
+ /* l2cap_reassemble_sdu may free skb, hence invalidate control, so store
+ * the txseq field in advance to use it after l2cap_reassemble_sdu
+ * returns and to avoid the race condition, for example:
+ *
+ * The current thread calls:
+ * l2cap_reassemble_sdu
+ * chan->ops->recv == l2cap_sock_recv_cb
+ * __sock_queue_rcv_skb
+ * Another thread calls:
+ * bt_sock_recvmsg
+ * skb_recv_datagram
+ * skb_free_datagram
+ * Then the current thread tries to access control, but it was freed by
+ * skb_free_datagram.
+ */
+ u16 txseq = control->txseq;
+
BT_DBG("chan %p, control %p, skb %p, state %d", chan, control, skb,
chan->rx_state);
- if (l2cap_classify_txseq(chan, control->txseq) ==
- L2CAP_TXSEQ_EXPECTED) {
+ if (l2cap_classify_txseq(chan, txseq) == L2CAP_TXSEQ_EXPECTED) {
l2cap_pass_to_tx(chan, control);
BT_DBG("buffer_seq %d->%d", chan->buffer_seq,
@@ -6712,8 +6746,8 @@ static int l2cap_stream_rx(struct l2cap_chan *chan, struct l2cap_ctrl *control,
}
}
- chan->last_acked_seq = control->txseq;
- chan->expected_tx_seq = __next_seq(chan, control->txseq);
+ chan->last_acked_seq = txseq;
+ chan->expected_tx_seq = __next_seq(chan, txseq);
return 0;
}
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 26/74] Bluetooth: L2CAP: fix use-after-free in l2cap_conn_del()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (24 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 25/74] Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 27/74] net: mdio: fix undefined behavior in bit shift for __mdiobus_register Greg Kroah-Hartman
` (54 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Zhengchao Shao,
Luiz Augusto von Dentz, Sasha Levin
From: Zhengchao Shao <shaozhengchao@huawei.com>
[ Upstream commit 0d0e2d032811280b927650ff3c15fe5020e82533 ]
When l2cap_recv_frame() is invoked to receive data, and the cid is
L2CAP_CID_A2MP, if the channel does not exist, it will create a channel.
However, after a channel is created, the hold operation of the channel
is not performed. In this case, the value of channel reference counting
is 1. As a result, after hci_error_reset() is triggered, l2cap_conn_del()
invokes the close hook function of A2MP to release the channel. Then
l2cap_chan_unlock(chan) will trigger UAF issue.
The process is as follows:
Receive data:
l2cap_data_channel()
a2mp_channel_create() --->channel ref is 2
l2cap_chan_put() --->channel ref is 1
Triger event:
hci_error_reset()
hci_dev_do_close()
...
l2cap_disconn_cfm()
l2cap_conn_del()
l2cap_chan_hold() --->channel ref is 2
l2cap_chan_del() --->channel ref is 1
a2mp_chan_close_cb() --->channel ref is 0, release channel
l2cap_chan_unlock() --->UAF of channel
The detailed Call Trace is as follows:
BUG: KASAN: use-after-free in __mutex_unlock_slowpath+0xa6/0x5e0
Read of size 8 at addr ffff8880160664b8 by task kworker/u11:1/7593
Workqueue: hci0 hci_error_reset
Call Trace:
<TASK>
dump_stack_lvl+0xcd/0x134
print_report.cold+0x2ba/0x719
kasan_report+0xb1/0x1e0
kasan_check_range+0x140/0x190
__mutex_unlock_slowpath+0xa6/0x5e0
l2cap_conn_del+0x404/0x7b0
l2cap_disconn_cfm+0x8c/0xc0
hci_conn_hash_flush+0x11f/0x260
hci_dev_close_sync+0x5f5/0x11f0
hci_dev_do_close+0x2d/0x70
hci_error_reset+0x9e/0x140
process_one_work+0x98a/0x1620
worker_thread+0x665/0x1080
kthread+0x2e4/0x3a0
ret_from_fork+0x1f/0x30
</TASK>
Allocated by task 7593:
kasan_save_stack+0x1e/0x40
__kasan_kmalloc+0xa9/0xd0
l2cap_chan_create+0x40/0x930
amp_mgr_create+0x96/0x990
a2mp_channel_create+0x7d/0x150
l2cap_recv_frame+0x51b8/0x9a70
l2cap_recv_acldata+0xaa3/0xc00
hci_rx_work+0x702/0x1220
process_one_work+0x98a/0x1620
worker_thread+0x665/0x1080
kthread+0x2e4/0x3a0
ret_from_fork+0x1f/0x30
Freed by task 7593:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_set_free_info+0x20/0x30
____kasan_slab_free+0x167/0x1c0
slab_free_freelist_hook+0x89/0x1c0
kfree+0xe2/0x580
l2cap_chan_put+0x22a/0x2d0
l2cap_conn_del+0x3fc/0x7b0
l2cap_disconn_cfm+0x8c/0xc0
hci_conn_hash_flush+0x11f/0x260
hci_dev_close_sync+0x5f5/0x11f0
hci_dev_do_close+0x2d/0x70
hci_error_reset+0x9e/0x140
process_one_work+0x98a/0x1620
worker_thread+0x665/0x1080
kthread+0x2e4/0x3a0
ret_from_fork+0x1f/0x30
Last potentially related work creation:
kasan_save_stack+0x1e/0x40
__kasan_record_aux_stack+0xbe/0xd0
call_rcu+0x99/0x740
netlink_release+0xe6a/0x1cf0
__sock_release+0xcd/0x280
sock_close+0x18/0x20
__fput+0x27c/0xa90
task_work_run+0xdd/0x1a0
exit_to_user_mode_prepare+0x23c/0x250
syscall_exit_to_user_mode+0x19/0x50
do_syscall_64+0x42/0x80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Second to last potentially related work creation:
kasan_save_stack+0x1e/0x40
__kasan_record_aux_stack+0xbe/0xd0
call_rcu+0x99/0x740
netlink_release+0xe6a/0x1cf0
__sock_release+0xcd/0x280
sock_close+0x18/0x20
__fput+0x27c/0xa90
task_work_run+0xdd/0x1a0
exit_to_user_mode_prepare+0x23c/0x250
syscall_exit_to_user_mode+0x19/0x50
do_syscall_64+0x42/0x80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Fixes: d0be8347c623 ("Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put")
Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bluetooth/l2cap_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 5fa9a4e7d3ee..5dbe7aeca5a7 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -7001,6 +7001,7 @@ static void l2cap_data_channel(struct l2cap_conn *conn, u16 cid,
return;
}
+ l2cap_chan_hold(chan);
l2cap_chan_lock(chan);
} else {
BT_DBG("unknown cid 0x%4.4x", cid);
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 27/74] net: mdio: fix undefined behavior in bit shift for __mdiobus_register
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (25 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 26/74] Bluetooth: L2CAP: fix use-after-free in l2cap_conn_del() Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 28/74] net, neigh: Fix null-ptr-deref in neigh_table_clear() Greg Kroah-Hartman
` (53 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Gaosheng Cui, Andrew Lunn,
Jakub Kicinski, Sasha Levin
From: Gaosheng Cui <cuigaosheng1@huawei.com>
[ Upstream commit 40e4eb324c59e11fcb927aa46742d28aba6ecb8a ]
Shifting signed 32-bit value by 31 bits is undefined, so changing
significant bit to unsigned. The UBSAN warning calltrace like below:
UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27
left shift of 1 by 31 places cannot be represented in type 'int'
Call Trace:
<TASK>
dump_stack_lvl+0x7d/0xa5
dump_stack+0x15/0x1b
ubsan_epilogue+0xe/0x4e
__ubsan_handle_shift_out_of_bounds+0x1e7/0x20c
__mdiobus_register+0x49d/0x4e0
fixed_mdio_bus_init+0xd8/0x12d
do_one_initcall+0x76/0x430
kernel_init_freeable+0x3b3/0x422
kernel_init+0x24/0x1e0
ret_from_fork+0x1f/0x30
</TASK>
Fixes: 4fd5f812c23c ("phylib: allow incremental scanning of an mii bus")
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20221031132645.168421-1-cuigaosheng1@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/phy/mdio_bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 05c24db507a2..757763735e1f 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -419,7 +419,7 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
bus->reset(bus);
for (i = 0; i < PHY_MAX_ADDR; i++) {
- if ((bus->phy_mask & (1 << i)) == 0) {
+ if ((bus->phy_mask & BIT(i)) == 0) {
struct phy_device *phydev;
phydev = mdiobus_scan(bus, i);
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 28/74] net, neigh: Fix null-ptr-deref in neigh_table_clear()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (26 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 27/74] net: mdio: fix undefined behavior in bit shift for __mdiobus_register Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 29/74] ipv6: fix WARNING in ip6_route_net_exit_late() Greg Kroah-Hartman
` (52 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Chen Zhongjin, Eric Dumazet,
Denis V. Lunev, Jakub Kicinski, Sasha Levin
From: Chen Zhongjin <chenzhongjin@huawei.com>
[ Upstream commit f8017317cb0b279b8ab98b0f3901a2e0ac880dad ]
When IPv6 module gets initialized but hits an error in the middle,
kenel panic with:
KASAN: null-ptr-deref in range [0x0000000000000598-0x000000000000059f]
CPU: 1 PID: 361 Comm: insmod
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:__neigh_ifdown.isra.0+0x24b/0x370
RSP: 0018:ffff888012677908 EFLAGS: 00000202
...
Call Trace:
<TASK>
neigh_table_clear+0x94/0x2d0
ndisc_cleanup+0x27/0x40 [ipv6]
inet6_init+0x21c/0x2cb [ipv6]
do_one_initcall+0xd3/0x4d0
do_init_module+0x1ae/0x670
...
Kernel panic - not syncing: Fatal exception
When ipv6 initialization fails, it will try to cleanup and calls:
neigh_table_clear()
neigh_ifdown(tbl, NULL)
pneigh_queue_purge(&tbl->proxy_queue, dev_net(dev == NULL))
# dev_net(NULL) triggers null-ptr-deref.
Fix it by passing NULL to pneigh_queue_purge() in neigh_ifdown() if dev
is NULL, to make kernel not panic immediately.
Fixes: 66ba215cb513 ("neigh: fix possible DoS due to net iface start/stop loop")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Denis V. Lunev <den@openvz.org>
Link: https://lore.kernel.org/r/20221101121552.21890-1-chenzhongjin@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/core/neighbour.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index aa81aead0a65..67820219e3b6 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -373,7 +373,7 @@ static int __neigh_ifdown(struct neigh_table *tbl, struct net_device *dev,
write_lock_bh(&tbl->lock);
neigh_flush_dev(tbl, dev, skip_perm);
pneigh_ifdown_and_unlock(tbl, dev);
- pneigh_queue_purge(&tbl->proxy_queue, dev_net(dev));
+ pneigh_queue_purge(&tbl->proxy_queue, dev ? dev_net(dev) : NULL);
if (skb_queue_empty_lockless(&tbl->proxy_queue))
del_timer_sync(&tbl->proxy_timer);
return 0;
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 29/74] ipv6: fix WARNING in ip6_route_net_exit_late()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (27 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 28/74] net, neigh: Fix null-ptr-deref in neigh_table_clear() Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 30/74] media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE Greg Kroah-Hartman
` (51 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Zhengchao Shao, Eric Dumazet,
Jakub Kicinski, Sasha Levin
From: Zhengchao Shao <shaozhengchao@huawei.com>
[ Upstream commit 768b3c745fe5789f2430bdab02f35a9ad1148d97 ]
During the initialization of ip6_route_net_init_late(), if file
ipv6_route or rt6_stats fails to be created, the initialization is
successful by default. Therefore, the ipv6_route or rt6_stats file
doesn't be found during the remove in ip6_route_net_exit_late(). It
will cause WRNING.
The following is the stack information:
name 'rt6_stats'
WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
PKRU: 55555554
Call Trace:
<TASK>
ops_exit_list+0xb0/0x170
cleanup_net+0x4ea/0xb00
process_one_work+0x9bf/0x1710
worker_thread+0x665/0x1080
kthread+0x2e4/0x3a0
ret_from_fork+0x1f/0x30
</TASK>
Fixes: cdb1876192db ("[NETNS][IPV6] route6 - create route6 proc files for the namespace")
Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20221102020610.351330-1-shaozhengchao@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/ipv6/route.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 00732ee6bbd8..badfe6939638 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -6359,10 +6359,16 @@ static void __net_exit ip6_route_net_exit(struct net *net)
static int __net_init ip6_route_net_init_late(struct net *net)
{
#ifdef CONFIG_PROC_FS
- proc_create_net("ipv6_route", 0, net->proc_net, &ipv6_route_seq_ops,
- sizeof(struct ipv6_route_iter));
- proc_create_net_single("rt6_stats", 0444, net->proc_net,
- rt6_stats_seq_show, NULL);
+ if (!proc_create_net("ipv6_route", 0, net->proc_net,
+ &ipv6_route_seq_ops,
+ sizeof(struct ipv6_route_iter)))
+ return -ENOMEM;
+
+ if (!proc_create_net_single("rt6_stats", 0444, net->proc_net,
+ rt6_stats_seq_show, NULL)) {
+ remove_proc_entry("ipv6_route", net->proc_net);
+ return -ENOMEM;
+ }
#endif
return 0;
}
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 30/74] media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (28 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 29/74] ipv6: fix WARNING in ip6_route_net_exit_late() Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:38 ` [PATCH 5.4 31/74] media: cros-ec-cec: " Greg Kroah-Hartman
` (50 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Hans Verkuil, Mauro Carvalho Chehab,
Sasha Levin
From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
[ Upstream commit 93f65ce036863893c164ca410938e0968964b26c ]
I expect that the hardware will have limited this to 16, but just in
case it hasn't, check for this corner case.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/s5p-cec/s5p_cec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/platform/s5p-cec/s5p_cec.c b/drivers/media/platform/s5p-cec/s5p_cec.c
index 828792b854f5..0c668d4a3daa 100644
--- a/drivers/media/platform/s5p-cec/s5p_cec.c
+++ b/drivers/media/platform/s5p-cec/s5p_cec.c
@@ -115,6 +115,8 @@ static irqreturn_t s5p_cec_irq_handler(int irq, void *priv)
dev_dbg(cec->dev, "Buffer overrun (worker did not process previous message)\n");
cec->rx = STATE_BUSY;
cec->msg.len = status >> 24;
+ if (cec->msg.len > CEC_MAX_MSG_SIZE)
+ cec->msg.len = CEC_MAX_MSG_SIZE;
cec->msg.rx_status = CEC_RX_STATUS_OK;
s5p_cec_get_rx_buf(cec, cec->msg.len,
cec->msg.msg);
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 31/74] media: cros-ec-cec: limit msg.len to CEC_MAX_MSG_SIZE
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (29 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 30/74] media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE Greg Kroah-Hartman
@ 2022-11-08 13:38 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 32/74] media: dvb-frontends/drxk: initialize err to 0 Greg Kroah-Hartman
` (49 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:38 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Hans Verkuil, Mauro Carvalho Chehab,
Sasha Levin
From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
[ Upstream commit 2dc73b48665411a08c4e5f0f823dea8510761603 ]
I expect that the hardware will have limited this to 16, but just in
case it hasn't, check for this corner case.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/platform/cros-ec-cec/cros-ec-cec.c b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
index 31390ce2dbf2..ae274a7aa3a9 100644
--- a/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
+++ b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
@@ -45,6 +45,8 @@ static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
uint8_t *cec_message = cros_ec->event_data.data.cec_message;
unsigned int len = cros_ec->event_size;
+ if (len > CEC_MAX_MSG_SIZE)
+ len = CEC_MAX_MSG_SIZE;
cros_ec_cec->rx_msg.len = len;
memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 32/74] media: dvb-frontends/drxk: initialize err to 0
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (30 preceding siblings ...)
2022-11-08 13:38 ` [PATCH 5.4 31/74] media: cros-ec-cec: " Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 33/74] media: meson: vdec: fix possible refcount leak in vdec_probe() Greg Kroah-Hartman
` (48 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Hans Verkuil, Mauro Carvalho Chehab,
Sasha Levin
From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
[ Upstream commit 20694e96ca089ce6693c2348f8f628ee621e4e74 ]
Fix a compiler warning:
drivers/media/dvb-frontends/drxk_hard.c: In function 'drxk_read_ucblocks':
drivers/media/dvb-frontends/drxk_hard.c:6673:21: warning: 'err' may be used uninitialized [-Wmaybe-uninitialized]
6673 | *ucblocks = (u32) err;
| ^~~~~~~~~
drivers/media/dvb-frontends/drxk_hard.c:6663:13: note: 'err' was declared here
6663 | u16 err;
| ^~~
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/dvb-frontends/drxk_hard.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/drxk_hard.c b/drivers/media/dvb-frontends/drxk_hard.c
index 0a4875b391d9..2dccc9d0be12 100644
--- a/drivers/media/dvb-frontends/drxk_hard.c
+++ b/drivers/media/dvb-frontends/drxk_hard.c
@@ -6684,7 +6684,7 @@ static int drxk_read_snr(struct dvb_frontend *fe, u16 *snr)
static int drxk_read_ucblocks(struct dvb_frontend *fe, u32 *ucblocks)
{
struct drxk_state *state = fe->demodulator_priv;
- u16 err;
+ u16 err = 0;
dprintk(1, "\n");
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 33/74] media: meson: vdec: fix possible refcount leak in vdec_probe()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (31 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 32/74] media: dvb-frontends/drxk: initialize err to 0 Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 34/74] scsi: core: Restrict legal sdev_state transitions via sysfs Greg Kroah-Hartman
` (47 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Hangyu Hua, Hans Verkuil,
Mauro Carvalho Chehab, Sasha Levin
From: Hangyu Hua <hbh25y@gmail.com>
[ Upstream commit 7718999356234d9cc6a11b4641bb773928f1390f ]
v4l2_device_unregister need to be called to put the refcount got by
v4l2_device_register when vdec_probe fails or vdec_remove is called.
Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/staging/media/meson/vdec/vdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/media/meson/vdec/vdec.c b/drivers/staging/media/meson/vdec/vdec.c
index 8dd1396909d7..a242bbe23ba2 100644
--- a/drivers/staging/media/meson/vdec/vdec.c
+++ b/drivers/staging/media/meson/vdec/vdec.c
@@ -1074,6 +1074,7 @@ static int vdec_probe(struct platform_device *pdev)
err_vdev_release:
video_device_release(vdev);
+ v4l2_device_unregister(&core->v4l2_dev);
return ret;
}
@@ -1082,6 +1083,7 @@ static int vdec_remove(struct platform_device *pdev)
struct amvdec_core *core = platform_get_drvdata(pdev);
video_unregister_device(core->vdev_dec);
+ v4l2_device_unregister(&core->v4l2_dev);
return 0;
}
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 34/74] scsi: core: Restrict legal sdev_state transitions via sysfs
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (32 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 33/74] media: meson: vdec: fix possible refcount leak in vdec_probe() Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 35/74] HID: saitek: add madcatz variant of MMO7 mouse device ID Greg Kroah-Hartman
` (46 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Uday Shankar, Mike Christie,
Hannes Reinecke, Martin K. Petersen, Sasha Levin
From: Uday Shankar <ushankar@purestorage.com>
[ Upstream commit 2331ce6126be8864b39490e705286b66e2344aac ]
Userspace can currently write to sysfs to transition sdev_state to RUNNING
or OFFLINE from any source state. This causes issues because proper
transitioning out of some states involves steps besides just changing
sdev_state, so allowing userspace to change sdev_state regardless of the
source state can result in inconsistencies; e.g. with ISCSI we can end up
with sdev_state == SDEV_RUNNING while the device queue is quiesced. Any
task attempting I/O on the device will then hang, and in more recent
kernels, iscsid will hang as well.
More detail about this bug is provided in my first attempt:
https://groups.google.com/g/open-iscsi/c/PNKca4HgPDs/m/CXaDkntOAQAJ
Link: https://lore.kernel.org/r/20220924000241.2967323-1-ushankar@purestorage.com
Signed-off-by: Uday Shankar <ushankar@purestorage.com>
Suggested-by: Mike Christie <michael.christie@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/scsi_sysfs.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 6faf1d6451b0..530b14685fd7 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -795,6 +795,14 @@ store_state_field(struct device *dev, struct device_attribute *attr,
}
mutex_lock(&sdev->state_mutex);
+ switch (sdev->sdev_state) {
+ case SDEV_RUNNING:
+ case SDEV_OFFLINE:
+ break;
+ default:
+ mutex_unlock(&sdev->state_mutex);
+ return -EINVAL;
+ }
if (sdev->sdev_state == SDEV_RUNNING && state == SDEV_RUNNING) {
ret = 0;
} else {
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 35/74] HID: saitek: add madcatz variant of MMO7 mouse device ID
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (33 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 34/74] scsi: core: Restrict legal sdev_state transitions via sysfs Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 36/74] i2c: xiic: Add platform module alias Greg Kroah-Hartman
` (45 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Samuel Bailey, Jiri Kosina, Sasha Levin
From: Samuel Bailey <samuel.bailey1@gmail.com>
[ Upstream commit 79425b297f56bd481c6e97700a9a4e44c7bcfa35 ]
The MadCatz variant of the MMO7 mouse has the ID 0738:1713 and the same
quirks as the Saitek variant.
Signed-off-by: Samuel Bailey <samuel.bailey1@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-quirks.c | 1 +
drivers/hid/hid-saitek.c | 2 ++
3 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index c587a77d493c..d6cd94cad571 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -818,6 +818,7 @@
#define USB_DEVICE_ID_MADCATZ_BEATPAD 0x4540
#define USB_DEVICE_ID_MADCATZ_RAT5 0x1705
#define USB_DEVICE_ID_MADCATZ_RAT9 0x1709
+#define USB_DEVICE_ID_MADCATZ_MMO7 0x1713
#define USB_VENDOR_ID_MCC 0x09db
#define USB_DEVICE_ID_MCC_PMD1024LS 0x0076
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 45eba224cdc7..89e236b71ddf 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -615,6 +615,7 @@ static const struct hid_device_id hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_MMO7) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MADCATZ, USB_DEVICE_ID_MADCATZ_RAT5) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MADCATZ, USB_DEVICE_ID_MADCATZ_RAT9) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MADCATZ, USB_DEVICE_ID_MADCATZ_MMO7) },
#endif
#if IS_ENABLED(CONFIG_HID_SAMSUNG)
{ HID_USB_DEVICE(USB_VENDOR_ID_SAMSUNG, USB_DEVICE_ID_SAMSUNG_IR_REMOTE) },
diff --git a/drivers/hid/hid-saitek.c b/drivers/hid/hid-saitek.c
index c7bf14c01960..b84e975977c4 100644
--- a/drivers/hid/hid-saitek.c
+++ b/drivers/hid/hid-saitek.c
@@ -187,6 +187,8 @@ static const struct hid_device_id saitek_devices[] = {
.driver_data = SAITEK_RELEASE_MODE_RAT7 },
{ HID_USB_DEVICE(USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_MMO7),
.driver_data = SAITEK_RELEASE_MODE_MMO7 },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MADCATZ, USB_DEVICE_ID_MADCATZ_MMO7),
+ .driver_data = SAITEK_RELEASE_MODE_MMO7 },
{ }
};
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 36/74] i2c: xiic: Add platform module alias
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (34 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 35/74] HID: saitek: add madcatz variant of MMO7 mouse device ID Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 37/74] xfs: dont fail verifier on empty attr3 leaf block Greg Kroah-Hartman
` (44 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Martin Tůma, Michal Simek,
Wolfram Sang, Sasha Levin
From: Martin Tůma <martin.tuma@digiteqautomotive.com>
[ Upstream commit b8caf0a0e04583fb71e21495bef84509182227ea ]
The missing "platform" alias is required for the mgb4 v4l2 driver to load
the i2c controller driver when probing the HW.
Signed-off-by: Martin Tůma <martin.tuma@digiteqautomotive.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/i2c/busses/i2c-xiic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c
index a48bee59dcde..c92ea6990ec6 100644
--- a/drivers/i2c/busses/i2c-xiic.c
+++ b/drivers/i2c/busses/i2c-xiic.c
@@ -884,6 +884,7 @@ static struct platform_driver xiic_i2c_driver = {
module_platform_driver(xiic_i2c_driver);
+MODULE_ALIAS("platform:" DRIVER_NAME);
MODULE_AUTHOR("info@mocean-labs.com");
MODULE_DESCRIPTION("Xilinx I2C bus driver");
MODULE_LICENSE("GPL v2");
--
2.35.1
^ permalink raw reply related [flat|nested] 82+ messages in thread* [PATCH 5.4 37/74] xfs: dont fail verifier on empty attr3 leaf block
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (35 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 36/74] i2c: xiic: Add platform module alias Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 38/74] xfs: use ordered buffers to initialize dquot buffers during quotacheck Greg Kroah-Hartman
` (43 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Brian Foster, Darrick J. Wong,
Christoph Hellwig, Darrick J. Wong, Chandan Babu R
From: Brian Foster <bfoster@redhat.com>
commit f28cef9e4daca11337cb9f144cdebedaab69d78c upstream.
The attr fork can transition from shortform to leaf format while
empty if the first xattr doesn't fit in shortform. While this empty
leaf block state is intended to be transient, it is technically not
due to the transactional implementation of the xattr set operation.
We historically have a couple of bandaids to work around this
problem. The first is to hold the buffer after the format conversion
to prevent premature writeback of the empty leaf buffer and the
second is to bypass the xattr count check in the verifier during
recovery. The latter assumes that the xattr set is also in the log
and will be recovered into the buffer soon after the empty leaf
buffer is reconstructed. This is not guaranteed, however.
If the filesystem crashes after the format conversion but before the
xattr set that induced it, only the format conversion may exist in
the log. When recovered, this creates a latent corrupted state on
the inode as any subsequent attempts to read the buffer fail due to
verifier failure. This includes further attempts to set xattrs on
the inode or attempts to destroy the attr fork, which prevents the
inode from ever being removed from the unlinked list.
To avoid this condition, accept that an empty attr leaf block is a
valid state and remove the count check from the verifier. This means
that on rare occasions an attr fork might exist in an unexpected
state, but is otherwise consistent and functional. Note that we
retain the logic to avoid racing with metadata writeback to reduce
the window where this can occur.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Chandan Babu R <chandan.babu@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/xfs/libxfs/xfs_attr_leaf.c | 8 --------
1 file changed, 8 deletions(-)
--- a/fs/xfs/libxfs/xfs_attr_leaf.c
+++ b/fs/xfs/libxfs/xfs_attr_leaf.c
@@ -251,14 +251,6 @@ xfs_attr3_leaf_verify(
return fa;
/*
- * In recovery there is a transient state where count == 0 is valid
- * because we may have transitioned an empty shortform attr to a leaf
- * if the attr didn't fit in shortform.
- */
- if (!xfs_log_in_recovery(mp) && ichdr.count == 0)
- return __this_address;
-
- /*
* firstused is the block offset of the first name info structure.
* Make sure it doesn't go off the block or crash into the header.
*/
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 38/74] xfs: use ordered buffers to initialize dquot buffers during quotacheck
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (36 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 37/74] xfs: dont fail verifier on empty attr3 leaf block Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 39/74] xfs: gut error handling in xfs_trans_unreserve_and_mod_sb() Greg Kroah-Hartman
` (42 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Darrick J. Wong, Brian Foster,
Christoph Hellwig, Darrick J. Wong, Chandan Babu R
From: "Darrick J. Wong" <darrick.wong@oracle.com>
commit 78bba5c812cc651cee51b64b786be926ab7fe2a9 upstream.
While QAing the new xfs_repair quotacheck code, I uncovered a quota
corruption bug resulting from a bad interaction between dquot buffer
initialization and quotacheck. The bug can be reproduced with the
following sequence:
# mkfs.xfs -f /dev/sdf
# mount /dev/sdf /opt -o usrquota
# su nobody -s /bin/bash -c 'touch /opt/barf'
# sync
# xfs_quota -x -c 'report -ahi' /opt
User quota on /opt (/dev/sdf)
Inodes
User ID Used Soft Hard Warn/Grace
---------- ---------------------------------
root 3 0 0 00 [------]
nobody 1 0 0 00 [------]
# xfs_io -x -c 'shutdown' /opt
# umount /opt
# mount /dev/sdf /opt -o usrquota
# touch /opt/man2
# xfs_quota -x -c 'report -ahi' /opt
User quota on /opt (/dev/sdf)
Inodes
User ID Used Soft Hard Warn/Grace
---------- ---------------------------------
root 1 0 0 00 [------]
nobody 1 0 0 00 [------]
# umount /opt
Notice how the initial quotacheck set the root dquot icount to 3
(rootino, rbmino, rsumino), but after shutdown -> remount -> recovery,
xfs_quota reports that the root dquot has only 1 icount. We haven't
deleted anything from the filesystem, which means that quota is now
under-counting. This behavior is not limited to icount or the root
dquot, but this is the shortest reproducer.
I traced the cause of this discrepancy to the way that we handle ondisk
dquot updates during quotacheck vs. regular fs activity. Normally, when
we allocate a disk block for a dquot, we log the buffer as a regular
(dquot) buffer. Subsequent updates to the dquots backed by that block
are done via separate dquot log item updates, which means that they
depend on the logged buffer update being written to disk before the
dquot items. Because individual dquots have their own LSN fields, that
initial dquot buffer must always be recovered.
However, the story changes for quotacheck, which can cause dquot block
allocations but persists the final dquot counter values via a delwri
list. Because recovery doesn't gate dquot buffer replay on an LSN, this
means that the initial dquot buffer can be replayed over the (newer)
contents that were delwritten at the end of quotacheck. In effect, this
re-initializes the dquot counters after they've been updated. If the
log does not contain any other dquot items to recover, the obsolete
dquot contents will not be corrected by log recovery.
Because quotacheck uses a transaction to log the setting of the CHKD
flags in the superblock, we skip quotacheck during the second mount
call, which allows the incorrect icount to remain.
Fix this by changing the ondisk dquot initialization function to use
ordered buffers to write out fresh dquot blocks if it detects that we're
running quotacheck. If the system goes down before quotacheck can
complete, the CHKD flags will not be set in the superblock and the next
mount will run quotacheck again, which can fix uninitialized dquot
buffers. This requires amending the defer code to maintaine ordered
buffer state across defer rolls for the sake of the dquot allocation
code.
For regular operations we preserve the current behavior since the dquot
items require properly initialized ondisk dquot records.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Chandan Babu R <chandan.babu@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/xfs/libxfs/xfs_defer.c | 10 +++++++-
fs/xfs/xfs_dquot.c | 56 +++++++++++++++++++++++++++++++++++-----------
2 files changed, 52 insertions(+), 14 deletions(-)
--- a/fs/xfs/libxfs/xfs_defer.c
+++ b/fs/xfs/libxfs/xfs_defer.c
@@ -234,10 +234,13 @@ xfs_defer_trans_roll(
struct xfs_log_item *lip;
struct xfs_buf *bplist[XFS_DEFER_OPS_NR_BUFS];
struct xfs_inode *iplist[XFS_DEFER_OPS_NR_INODES];
+ unsigned int ordered = 0; /* bitmap */
int bpcount = 0, ipcount = 0;
int i;
int error;
+ BUILD_BUG_ON(NBBY * sizeof(ordered) < XFS_DEFER_OPS_NR_BUFS);
+
list_for_each_entry(lip, &tp->t_items, li_trans) {
switch (lip->li_type) {
case XFS_LI_BUF:
@@ -248,7 +251,10 @@ xfs_defer_trans_roll(
ASSERT(0);
return -EFSCORRUPTED;
}
- xfs_trans_dirty_buf(tp, bli->bli_buf);
+ if (bli->bli_flags & XFS_BLI_ORDERED)
+ ordered |= (1U << bpcount);
+ else
+ xfs_trans_dirty_buf(tp, bli->bli_buf);
bplist[bpcount++] = bli->bli_buf;
}
break;
@@ -289,6 +295,8 @@ xfs_defer_trans_roll(
/* Rejoin the buffers and dirty them so the log moves forward. */
for (i = 0; i < bpcount; i++) {
xfs_trans_bjoin(tp, bplist[i]);
+ if (ordered & (1U << i))
+ xfs_trans_ordered_buf(tp, bplist[i]);
xfs_trans_bhold(tp, bplist[i]);
}
--- a/fs/xfs/xfs_dquot.c
+++ b/fs/xfs/xfs_dquot.c
@@ -205,16 +205,18 @@ xfs_qm_adjust_dqtimers(
*/
STATIC void
xfs_qm_init_dquot_blk(
- xfs_trans_t *tp,
- xfs_mount_t *mp,
- xfs_dqid_t id,
- uint type,
- xfs_buf_t *bp)
+ struct xfs_trans *tp,
+ struct xfs_mount *mp,
+ xfs_dqid_t id,
+ uint type,
+ struct xfs_buf *bp)
{
struct xfs_quotainfo *q = mp->m_quotainfo;
- xfs_dqblk_t *d;
- xfs_dqid_t curid;
- int i;
+ struct xfs_dqblk *d;
+ xfs_dqid_t curid;
+ unsigned int qflag;
+ unsigned int blftype;
+ int i;
ASSERT(tp);
ASSERT(xfs_buf_islocked(bp));
@@ -238,11 +240,39 @@ xfs_qm_init_dquot_blk(
}
}
- xfs_trans_dquot_buf(tp, bp,
- (type & XFS_DQ_USER ? XFS_BLF_UDQUOT_BUF :
- ((type & XFS_DQ_PROJ) ? XFS_BLF_PDQUOT_BUF :
- XFS_BLF_GDQUOT_BUF)));
- xfs_trans_log_buf(tp, bp, 0, BBTOB(q->qi_dqchunklen) - 1);
+ if (type & XFS_DQ_USER) {
+ qflag = XFS_UQUOTA_CHKD;
+ blftype = XFS_BLF_UDQUOT_BUF;
+ } else if (type & XFS_DQ_PROJ) {
+ qflag = XFS_PQUOTA_CHKD;
+ blftype = XFS_BLF_PDQUOT_BUF;
+ } else {
+ qflag = XFS_GQUOTA_CHKD;
+ blftype = XFS_BLF_GDQUOT_BUF;
+ }
+
+ xfs_trans_dquot_buf(tp, bp, blftype);
+
+ /*
+ * quotacheck uses delayed writes to update all the dquots on disk in an
+ * efficient manner instead of logging the individual dquot changes as
+ * they are made. However if we log the buffer allocated here and crash
+ * after quotacheck while the logged initialisation is still in the
+ * active region of the log, log recovery can replay the dquot buffer
+ * initialisation over the top of the checked dquots and corrupt quota
+ * accounting.
+ *
+ * To avoid this problem, quotacheck cannot log the initialised buffer.
+ * We must still dirty the buffer and write it back before the
+ * allocation transaction clears the log. Therefore, mark the buffer as
+ * ordered instead of logging it directly. This is safe for quotacheck
+ * because it detects and repairs allocated but initialized dquot blocks
+ * in the quota inodes.
+ */
+ if (!(mp->m_qflags & qflag))
+ xfs_trans_ordered_buf(tp, bp);
+ else
+ xfs_trans_log_buf(tp, bp, 0, BBTOB(q->qi_dqchunklen) - 1);
}
/*
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 39/74] xfs: gut error handling in xfs_trans_unreserve_and_mod_sb()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (37 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 38/74] xfs: use ordered buffers to initialize dquot buffers during quotacheck Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 40/74] xfs: group quota should return EDQUOT when prj quota enabled Greg Kroah-Hartman
` (41 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Dave Chinner, Christoph Hellwig,
Darrick J. Wong, Darrick J. Wong, Chandan Babu R
From: Dave Chinner <david@fromorbit.com>
commit dc3ffbb14060c943469d5e12900db3a60bc3fa64 upstream.
The error handling in xfs_trans_unreserve_and_mod_sb() is largely
incorrect - rolling back the changes in the transaction if only one
counter underruns makes all the other counters incorrect. We still
allow the change to proceed and committing the transaction, except
now we have multiple incorrect counters instead of a single
underflow.
Further, we don't actually report the error to the caller, so this
is completely silent except on debug kernels that will assert on
failure before we even get to the rollback code. Hence this error
handling is broken, untested, and largely unnecessary complexity.
Just remove it.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Chandan Babu R <chandan.babu@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/xfs/xfs_trans.c | 163 ++++++-----------------------------------------------
1 file changed, 20 insertions(+), 143 deletions(-)
--- a/fs/xfs/xfs_trans.c
+++ b/fs/xfs/xfs_trans.c
@@ -532,57 +532,9 @@ xfs_trans_apply_sb_deltas(
sizeof(sbp->sb_frextents) - 1);
}
-STATIC int
-xfs_sb_mod8(
- uint8_t *field,
- int8_t delta)
-{
- int8_t counter = *field;
-
- counter += delta;
- if (counter < 0) {
- ASSERT(0);
- return -EINVAL;
- }
- *field = counter;
- return 0;
-}
-
-STATIC int
-xfs_sb_mod32(
- uint32_t *field,
- int32_t delta)
-{
- int32_t counter = *field;
-
- counter += delta;
- if (counter < 0) {
- ASSERT(0);
- return -EINVAL;
- }
- *field = counter;
- return 0;
-}
-
-STATIC int
-xfs_sb_mod64(
- uint64_t *field,
- int64_t delta)
-{
- int64_t counter = *field;
-
- counter += delta;
- if (counter < 0) {
- ASSERT(0);
- return -EINVAL;
- }
- *field = counter;
- return 0;
-}
-
/*
- * xfs_trans_unreserve_and_mod_sb() is called to release unused reservations
- * and apply superblock counter changes to the in-core superblock. The
+ * xfs_trans_unreserve_and_mod_sb() is called to release unused reservations and
+ * apply superblock counter changes to the in-core superblock. The
* t_res_fdblocks_delta and t_res_frextents_delta fields are explicitly NOT
* applied to the in-core superblock. The idea is that that has already been
* done.
@@ -627,20 +579,17 @@ xfs_trans_unreserve_and_mod_sb(
/* apply the per-cpu counters */
if (blkdelta) {
error = xfs_mod_fdblocks(mp, blkdelta, rsvd);
- if (error)
- goto out;
+ ASSERT(!error);
}
if (idelta) {
error = xfs_mod_icount(mp, idelta);
- if (error)
- goto out_undo_fdblocks;
+ ASSERT(!error);
}
if (ifreedelta) {
error = xfs_mod_ifree(mp, ifreedelta);
- if (error)
- goto out_undo_icount;
+ ASSERT(!error);
}
if (rtxdelta == 0 && !(tp->t_flags & XFS_TRANS_SB_DIRTY))
@@ -648,95 +597,23 @@ xfs_trans_unreserve_and_mod_sb(
/* apply remaining deltas */
spin_lock(&mp->m_sb_lock);
- if (rtxdelta) {
- error = xfs_sb_mod64(&mp->m_sb.sb_frextents, rtxdelta);
- if (error)
- goto out_undo_ifree;
- }
-
- if (tp->t_dblocks_delta != 0) {
- error = xfs_sb_mod64(&mp->m_sb.sb_dblocks, tp->t_dblocks_delta);
- if (error)
- goto out_undo_frextents;
- }
- if (tp->t_agcount_delta != 0) {
- error = xfs_sb_mod32(&mp->m_sb.sb_agcount, tp->t_agcount_delta);
- if (error)
- goto out_undo_dblocks;
- }
- if (tp->t_imaxpct_delta != 0) {
- error = xfs_sb_mod8(&mp->m_sb.sb_imax_pct, tp->t_imaxpct_delta);
- if (error)
- goto out_undo_agcount;
- }
- if (tp->t_rextsize_delta != 0) {
- error = xfs_sb_mod32(&mp->m_sb.sb_rextsize,
- tp->t_rextsize_delta);
- if (error)
- goto out_undo_imaxpct;
- }
- if (tp->t_rbmblocks_delta != 0) {
- error = xfs_sb_mod32(&mp->m_sb.sb_rbmblocks,
- tp->t_rbmblocks_delta);
- if (error)
- goto out_undo_rextsize;
- }
- if (tp->t_rblocks_delta != 0) {
- error = xfs_sb_mod64(&mp->m_sb.sb_rblocks, tp->t_rblocks_delta);
- if (error)
- goto out_undo_rbmblocks;
- }
- if (tp->t_rextents_delta != 0) {
- error = xfs_sb_mod64(&mp->m_sb.sb_rextents,
- tp->t_rextents_delta);
- if (error)
- goto out_undo_rblocks;
- }
- if (tp->t_rextslog_delta != 0) {
- error = xfs_sb_mod8(&mp->m_sb.sb_rextslog,
- tp->t_rextslog_delta);
- if (error)
- goto out_undo_rextents;
- }
+ mp->m_sb.sb_frextents += rtxdelta;
+ mp->m_sb.sb_dblocks += tp->t_dblocks_delta;
+ mp->m_sb.sb_agcount += tp->t_agcount_delta;
+ mp->m_sb.sb_imax_pct += tp->t_imaxpct_delta;
+ mp->m_sb.sb_rextsize += tp->t_rextsize_delta;
+ mp->m_sb.sb_rbmblocks += tp->t_rbmblocks_delta;
+ mp->m_sb.sb_rblocks += tp->t_rblocks_delta;
+ mp->m_sb.sb_rextents += tp->t_rextents_delta;
+ mp->m_sb.sb_rextslog += tp->t_rextslog_delta;
spin_unlock(&mp->m_sb_lock);
- return;
-out_undo_rextents:
- if (tp->t_rextents_delta)
- xfs_sb_mod64(&mp->m_sb.sb_rextents, -tp->t_rextents_delta);
-out_undo_rblocks:
- if (tp->t_rblocks_delta)
- xfs_sb_mod64(&mp->m_sb.sb_rblocks, -tp->t_rblocks_delta);
-out_undo_rbmblocks:
- if (tp->t_rbmblocks_delta)
- xfs_sb_mod32(&mp->m_sb.sb_rbmblocks, -tp->t_rbmblocks_delta);
-out_undo_rextsize:
- if (tp->t_rextsize_delta)
- xfs_sb_mod32(&mp->m_sb.sb_rextsize, -tp->t_rextsize_delta);
-out_undo_imaxpct:
- if (tp->t_rextsize_delta)
- xfs_sb_mod8(&mp->m_sb.sb_imax_pct, -tp->t_imaxpct_delta);
-out_undo_agcount:
- if (tp->t_agcount_delta)
- xfs_sb_mod32(&mp->m_sb.sb_agcount, -tp->t_agcount_delta);
-out_undo_dblocks:
- if (tp->t_dblocks_delta)
- xfs_sb_mod64(&mp->m_sb.sb_dblocks, -tp->t_dblocks_delta);
-out_undo_frextents:
- if (rtxdelta)
- xfs_sb_mod64(&mp->m_sb.sb_frextents, -rtxdelta);
-out_undo_ifree:
- spin_unlock(&mp->m_sb_lock);
- if (ifreedelta)
- xfs_mod_ifree(mp, -ifreedelta);
-out_undo_icount:
- if (idelta)
- xfs_mod_icount(mp, -idelta);
-out_undo_fdblocks:
- if (blkdelta)
- xfs_mod_fdblocks(mp, -blkdelta, rsvd);
-out:
- ASSERT(error == 0);
+ /*
+ * Debug checks outside of the spinlock so they don't lock up the
+ * machine if they fail.
+ */
+ ASSERT(mp->m_sb.sb_imax_pct >= 0);
+ ASSERT(mp->m_sb.sb_rextslog >= 0);
return;
}
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 40/74] xfs: group quota should return EDQUOT when prj quota enabled
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (38 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 39/74] xfs: gut error handling in xfs_trans_unreserve_and_mod_sb() Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 41/74] xfs: dont fail unwritten extent conversion on writeback due to edquot Greg Kroah-Hartman
` (40 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Eric Sandeen, Christoph Hellwig,
Brian Foster, Darrick J. Wong, Darrick J. Wong, Chandan Babu R
From: Eric Sandeen <sandeen@redhat.com>
commit c8d329f311c4d3d8f8e6dc5897ec235e37f48ae8 upstream.
Long ago, group & project quota were mutually exclusive, and so
when we turned on XFS_QMOPT_ENOSPC ("return ENOSPC if project quota
is exceeded") when project quota was enabled, we only needed to
disable it again for user quota.
When group & project quota got separated, this got missed, and as a
result if project quota is enabled and group quota is exceeded, the
error code returned is incorrectly returned as ENOSPC not EDQUOT.
Fix this by stripping XFS_QMOPT_ENOSPC out of flags for group
quota when we try to reserve the space.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Chandan Babu R <chandan.babu@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/xfs/xfs_trans_dquot.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/xfs/xfs_trans_dquot.c
+++ b/fs/xfs/xfs_trans_dquot.c
@@ -756,7 +756,8 @@ xfs_trans_reserve_quota_bydquots(
}
if (gdqp) {
- error = xfs_trans_dqresv(tp, mp, gdqp, nblks, ninos, flags);
+ error = xfs_trans_dqresv(tp, mp, gdqp, nblks, ninos,
+ (flags & ~XFS_QMOPT_ENOSPC));
if (error)
goto unwind_usr;
}
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 41/74] xfs: dont fail unwritten extent conversion on writeback due to edquot
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (39 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 40/74] xfs: group quota should return EDQUOT when prj quota enabled Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 42/74] xfs: Add the missed xfs_perag_put() for xfs_ifree_cluster() Greg Kroah-Hartman
` (39 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Darrick J. Wong, Brian Foster,
Christoph Hellwig, Darrick J. Wong, Chandan Babu R
From: "Darrick J. Wong" <darrick.wong@oracle.com>
commit 1edd2c055dff9710b1e29d4df01902abb0a55f1f upstream.
During writeback, it's possible for the quota block reservation in
xfs_iomap_write_unwritten to fail with EDQUOT because we hit the quota
limit. This causes writeback errors for data that was already written
to disk, when it's not even guaranteed that the bmbt will expand to
exceed the quota limit. Irritatingly, this condition is reported to
userspace as EIO by fsync, which is confusing.
We wrote the data, so allow the reservation. That might put us slightly
above the hard limit, but it's better than losing data after a write.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Chandan Babu R <chandan.babu@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/xfs/xfs_iomap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -789,7 +789,7 @@ xfs_iomap_write_unwritten(
xfs_trans_ijoin(tp, ip, 0);
error = xfs_trans_reserve_quota_nblks(tp, ip, resblks, 0,
- XFS_QMOPT_RES_REGBLKS);
+ XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES);
if (error)
goto error_on_bmapi_transaction;
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 42/74] xfs: Add the missed xfs_perag_put() for xfs_ifree_cluster()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (40 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 41/74] xfs: dont fail unwritten extent conversion on writeback due to edquot Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 43/74] Bluetooth: L2CAP: Fix attempting to access uninitialized memory Greg Kroah-Hartman
` (38 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Chuhong Yuan, Darrick J. Wong,
Darrick J. Wong, Chandan Babu R
From: Chuhong Yuan <hslester96@gmail.com>
commit 8cc0072469723459dc6bd7beff81b2b3149f4cf4 upstream.
xfs_ifree_cluster() calls xfs_perag_get() at the beginning, but forgets to
call xfs_perag_put() in one failed path.
Add the missed function call to fix it.
Fixes: ce92464c180b ("xfs: make xfs_trans_get_buf return an error code")
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Chandan Babu R <chandan.babu@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/xfs/xfs_inode.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -2592,8 +2592,10 @@ xfs_ifree_cluster(
mp->m_bsize * igeo->blocks_per_cluster,
XBF_UNMAPPED);
- if (!bp)
+ if (!bp) {
+ xfs_perag_put(pag);
return -ENOMEM;
+ }
/*
* This buffer may not have been correctly initialised as we
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 43/74] Bluetooth: L2CAP: Fix attempting to access uninitialized memory
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (41 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 42/74] xfs: Add the missed xfs_perag_put() for xfs_ifree_cluster() Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 44/74] block, bfq: protect bfqd->queued by bfqd->lock Greg Kroah-Hartman
` (37 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Tamás Koczka,
Luiz Augusto von Dentz, Tedd Ho-Jeong An
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
commit b1a2cd50c0357f243b7435a732b4e62ba3157a2e upstream.
On l2cap_parse_conf_req the variable efs is only initialized if
remote_efs has been set.
CVE: CVE-2022-42895
CC: stable@vger.kernel.org
Reported-by: Tamás Koczka <poprdi@google.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Reviewed-by: Tedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/bluetooth/l2cap_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -3560,7 +3560,8 @@ done:
l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC,
sizeof(rfc), (unsigned long) &rfc, endptr - ptr);
- if (test_bit(FLAG_EFS_ENABLE, &chan->flags)) {
+ if (remote_efs &&
+ test_bit(FLAG_EFS_ENABLE, &chan->flags)) {
chan->remote_id = efs.id;
chan->remote_stype = efs.stype;
chan->remote_msdu = le16_to_cpu(efs.msdu);
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 44/74] block, bfq: protect bfqd->queued by bfqd->lock
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (42 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 43/74] Bluetooth: L2CAP: Fix attempting to access uninitialized memory Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 45/74] tcp/udp: Fix memory leak in ipv6_renew_options() Greg Kroah-Hartman
` (36 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Yu Kuai, Jan Kara,
Chaitanya Kulkarni, Jens Axboe, Khazhy Kumykov
From: Yu Kuai <yukuai3@huawei.com>
commit 181490d5321806e537dc5386db5ea640b826bf78 upstream.
If bfq_schedule_dispatch() is called from bfq_idle_slice_timer_body(),
then 'bfqd->queued' is read without holding 'bfqd->lock'. This is
wrong since it can be wrote concurrently.
Fix the problem by holding 'bfqd->lock' in such case.
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Link: https://lore.kernel.org/r/20220513023507.2625717-2-yukuai3@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Cc: Khazhy Kumykov <khazhy@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
block/bfq-iosched.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -420,6 +420,8 @@ static struct bfq_io_cq *bfq_bic_lookup(
*/
void bfq_schedule_dispatch(struct bfq_data *bfqd)
{
+ lockdep_assert_held(&bfqd->lock);
+
if (bfqd->queued != 0) {
bfq_log(bfqd, "schedule dispatch");
blk_mq_run_hw_queues(bfqd->queue, true);
@@ -6257,8 +6259,8 @@ bfq_idle_slice_timer_body(struct bfq_dat
bfq_bfqq_expire(bfqd, bfqq, true, reason);
schedule_dispatch:
- spin_unlock_irqrestore(&bfqd->lock, flags);
bfq_schedule_dispatch(bfqd);
+ spin_unlock_irqrestore(&bfqd->lock, flags);
}
/*
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 45/74] tcp/udp: Fix memory leak in ipv6_renew_options().
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (43 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 44/74] block, bfq: protect bfqd->queued by bfqd->lock Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 46/74] memcg: enable accounting of ipc resources Greg Kroah-Hartman
` (35 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, syzbot, Kuniyuki Iwashima,
Jakub Kicinski, Meena Shanmugam
From: Kuniyuki Iwashima <kuniyu@amazon.com>
commit 3c52c6bb831f6335c176a0fc7214e26f43adbd11 upstream.
syzbot reported a memory leak [0] related to IPV6_ADDRFORM.
The scenario is that while one thread is converting an IPv6 socket into
IPv4 with IPV6_ADDRFORM, another thread calls do_ipv6_setsockopt() and
allocates memory to inet6_sk(sk)->XXX after conversion.
Then, the converted sk with (tcp|udp)_prot never frees the IPv6 resources,
which inet6_destroy_sock() should have cleaned up.
setsockopt(IPV6_ADDRFORM) setsockopt(IPV6_DSTOPTS)
+-----------------------+ +----------------------+
- do_ipv6_setsockopt(sk, ...)
- sockopt_lock_sock(sk) - do_ipv6_setsockopt(sk, ...)
- lock_sock(sk) ^._ called via tcpv6_prot
- WRITE_ONCE(sk->sk_prot, &tcp_prot) before WRITE_ONCE()
- xchg(&np->opt, NULL)
- txopt_put(opt)
- sockopt_release_sock(sk)
- release_sock(sk) - sockopt_lock_sock(sk)
- lock_sock(sk)
- ipv6_set_opt_hdr(sk, ...)
- ipv6_update_options(sk, opt)
- xchg(&inet6_sk(sk)->opt, opt)
^._ opt is never freed.
- sockopt_release_sock(sk)
- release_sock(sk)
Since IPV6_DSTOPTS allocates options under lock_sock(), we can avoid this
memory leak by testing whether sk_family is changed by IPV6_ADDRFORM after
acquiring the lock.
This issue exists from the initial commit between IPV6_ADDRFORM and
IPV6_PKTOPTIONS.
[0]:
BUG: memory leak
unreferenced object 0xffff888009ab9f80 (size 96):
comm "syz-executor583", pid 328, jiffies 4294916198 (age 13.034s)
hex dump (first 32 bytes):
01 00 00 00 48 00 00 00 08 00 00 00 00 00 00 00 ....H...........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000002ee98ae1>] kmalloc include/linux/slab.h:605 [inline]
[<000000002ee98ae1>] sock_kmalloc+0xb3/0x100 net/core/sock.c:2566
[<0000000065d7b698>] ipv6_renew_options+0x21e/0x10b0 net/ipv6/exthdrs.c:1318
[<00000000a8c756d7>] ipv6_set_opt_hdr net/ipv6/ipv6_sockglue.c:354 [inline]
[<00000000a8c756d7>] do_ipv6_setsockopt.constprop.0+0x28b7/0x4350 net/ipv6/ipv6_sockglue.c:668
[<000000002854d204>] ipv6_setsockopt+0xdf/0x190 net/ipv6/ipv6_sockglue.c:1021
[<00000000e69fdcf8>] tcp_setsockopt+0x13b/0x2620 net/ipv4/tcp.c:3789
[<0000000090da4b9b>] __sys_setsockopt+0x239/0x620 net/socket.c:2252
[<00000000b10d192f>] __do_sys_setsockopt net/socket.c:2263 [inline]
[<00000000b10d192f>] __se_sys_setsockopt net/socket.c:2260 [inline]
[<00000000b10d192f>] __x64_sys_setsockopt+0xbe/0x160 net/socket.c:2260
[<000000000a80d7aa>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<000000000a80d7aa>] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80
[<000000004562b5c6>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Meena Shanmugam <meenashanmugam@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/ipv6_sockglue.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -164,6 +164,12 @@ static int do_ipv6_setsockopt(struct soc
rtnl_lock();
lock_sock(sk);
+ /* Another thread has converted the socket into IPv4 with
+ * IPV6_ADDRFORM concurrently.
+ */
+ if (unlikely(sk->sk_family != AF_INET6))
+ goto unlock;
+
switch (optname) {
case IPV6_ADDRFORM:
@@ -924,6 +930,7 @@ pref_skip_coa:
break;
}
+unlock:
release_sock(sk);
if (needs_rtnl)
rtnl_unlock();
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 46/74] memcg: enable accounting of ipc resources
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (44 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 45/74] tcp/udp: Fix memory leak in ipv6_renew_options() Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 47/74] binder: fix UAF of alloc->vma in race with munmap() Greg Kroah-Hartman
` (34 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Vasily Averin, Shakeel Butt,
Alexander Viro, Alexey Dobriyan, Andrei Vagin, Borislav Petkov,
Borislav Petkov, Christian Brauner, Dmitry Safonov,
Eric W. Biederman, H. Peter Anvin, Ingo Molnar, J. Bruce Fields,
Jeff Layton, Jens Axboe, Jiri Slaby, Johannes Weiner,
Kirill Tkhai, Michal Hocko, Oleg Nesterov, Roman Gushchin,
Serge Hallyn, Tejun Heo, Thomas Gleixner, Vladimir Davydov,
Yutian Yang, Zefan Li, Andrew Morton, Linus Torvalds,
Luiz Capitulino
From: Vasily Averin <vvs@virtuozzo.com>
commit 18319498fdd4cdf8c1c2c48cd432863b1f915d6f upstream.
When user creates IPC objects it forces kernel to allocate memory for
these long-living objects.
It makes sense to account them to restrict the host's memory consumption
from inside the memcg-limited container.
This patch enables accounting for IPC shared memory segments, messages
semaphores and semaphore's undo lists.
Link: https://lkml.kernel.org/r/d6507b06-4df6-78f8-6c54-3ae86e3b5339@virtuozzo.com
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Andrei Vagin <avagin@gmail.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Borislav Petkov <bp@suse.de>
Cc: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Dmitry Safonov <0x7f454c46@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Jeff Layton <jlayton@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Jiri Slaby <jirislaby@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Roman Gushchin <guro@fb.com>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Yutian Yang <nglaive@gmail.com>
Cc: Zefan Li <lizefan.x@bytedance.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Luiz Capitulino <luizcap@amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
ipc/msg.c | 2 +-
ipc/sem.c | 9 +++++----
ipc/shm.c | 2 +-
3 files changed, 7 insertions(+), 6 deletions(-)
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -137,7 +137,7 @@ static int newque(struct ipc_namespace *
key_t key = params->key;
int msgflg = params->flg;
- msq = kvmalloc(sizeof(*msq), GFP_KERNEL);
+ msq = kvmalloc(sizeof(*msq), GFP_KERNEL_ACCOUNT);
if (unlikely(!msq))
return -ENOMEM;
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -492,7 +492,7 @@ static struct sem_array *sem_alloc(size_
if (nsems > (INT_MAX - sizeof(*sma)) / sizeof(sma->sems[0]))
return NULL;
- sma = kvzalloc(struct_size(sma, sems, nsems), GFP_KERNEL);
+ sma = kvzalloc(struct_size(sma, sems, nsems), GFP_KERNEL_ACCOUNT);
if (unlikely(!sma))
return NULL;
@@ -1835,7 +1835,7 @@ static inline int get_undo_list(struct s
undo_list = current->sysvsem.undo_list;
if (!undo_list) {
- undo_list = kzalloc(sizeof(*undo_list), GFP_KERNEL);
+ undo_list = kzalloc(sizeof(*undo_list), GFP_KERNEL_ACCOUNT);
if (undo_list == NULL)
return -ENOMEM;
spin_lock_init(&undo_list->lock);
@@ -1920,7 +1920,7 @@ static struct sem_undo *find_alloc_undo(
rcu_read_unlock();
/* step 2: allocate new undo structure */
- new = kzalloc(sizeof(struct sem_undo) + sizeof(short)*nsems, GFP_KERNEL);
+ new = kzalloc(sizeof(struct sem_undo) + sizeof(short)*nsems, GFP_KERNEL_ACCOUNT);
if (!new) {
ipc_rcu_putref(&sma->sem_perm, sem_rcu_free);
return ERR_PTR(-ENOMEM);
@@ -1984,7 +1984,8 @@ static long do_semtimedop(int semid, str
if (nsops > ns->sc_semopm)
return -E2BIG;
if (nsops > SEMOPM_FAST) {
- sops = kvmalloc_array(nsops, sizeof(*sops), GFP_KERNEL);
+ sops = kvmalloc_array(nsops, sizeof(*sops),
+ GFP_KERNEL_ACCOUNT);
if (sops == NULL)
return -ENOMEM;
}
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -711,7 +711,7 @@ static int newseg(struct ipc_namespace *
ns->shm_tot + numpages > ns->shm_ctlall)
return -ENOSPC;
- shp = kvmalloc(sizeof(*shp), GFP_KERNEL);
+ shp = kvmalloc(sizeof(*shp), GFP_KERNEL_ACCOUNT);
if (unlikely(!shp))
return -ENOMEM;
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 47/74] binder: fix UAF of alloc->vma in race with munmap()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (45 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 46/74] memcg: enable accounting of ipc resources Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 48/74] btrfs: fix type of parameter generation in btrfs_get_dentry Greg Kroah-Hartman
` (33 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Jann Horn, Minchan Kim, Yang Shi,
Liam Howlett, Carlos Llamas
From: Carlos Llamas <cmllamas@google.com>
In commit 720c24192404 ("ANDROID: binder: change down_write to
down_read") binder assumed the mmap read lock is sufficient to protect
alloc->vma inside binder_update_page_range(). This used to be accurate
until commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in
munmap"), which now downgrades the mmap_lock after detaching the vma
from the rbtree in munmap(). Then it proceeds to teardown and free the
vma with only the read lock held.
This means that accesses to alloc->vma in binder_update_page_range() now
will race with vm_area_free() in munmap() and can cause a UAF as shown
in the following KASAN trace:
==================================================================
BUG: KASAN: use-after-free in vm_insert_page+0x7c/0x1f0
Read of size 8 at addr ffff16204ad00600 by task server/558
CPU: 3 PID: 558 Comm: server Not tainted 5.10.150-00001-gdc8dcf942daa #1
Hardware name: linux,dummy-virt (DT)
Call trace:
dump_backtrace+0x0/0x2a0
show_stack+0x18/0x2c
dump_stack+0xf8/0x164
print_address_description.constprop.0+0x9c/0x538
kasan_report+0x120/0x200
__asan_load8+0xa0/0xc4
vm_insert_page+0x7c/0x1f0
binder_update_page_range+0x278/0x50c
binder_alloc_new_buf+0x3f0/0xba0
binder_transaction+0x64c/0x3040
binder_thread_write+0x924/0x2020
binder_ioctl+0x1610/0x2e5c
__arm64_sys_ioctl+0xd4/0x120
el0_svc_common.constprop.0+0xac/0x270
do_el0_svc+0x38/0xa0
el0_svc+0x1c/0x2c
el0_sync_handler+0xe8/0x114
el0_sync+0x180/0x1c0
Allocated by task 559:
kasan_save_stack+0x38/0x6c
__kasan_kmalloc.constprop.0+0xe4/0xf0
kasan_slab_alloc+0x18/0x2c
kmem_cache_alloc+0x1b0/0x2d0
vm_area_alloc+0x28/0x94
mmap_region+0x378/0x920
do_mmap+0x3f0/0x600
vm_mmap_pgoff+0x150/0x17c
ksys_mmap_pgoff+0x284/0x2dc
__arm64_sys_mmap+0x84/0xa4
el0_svc_common.constprop.0+0xac/0x270
do_el0_svc+0x38/0xa0
el0_svc+0x1c/0x2c
el0_sync_handler+0xe8/0x114
el0_sync+0x180/0x1c0
Freed by task 560:
kasan_save_stack+0x38/0x6c
kasan_set_track+0x28/0x40
kasan_set_free_info+0x24/0x4c
__kasan_slab_free+0x100/0x164
kasan_slab_free+0x14/0x20
kmem_cache_free+0xc4/0x34c
vm_area_free+0x1c/0x2c
remove_vma+0x7c/0x94
__do_munmap+0x358/0x710
__vm_munmap+0xbc/0x130
__arm64_sys_munmap+0x4c/0x64
el0_svc_common.constprop.0+0xac/0x270
do_el0_svc+0x38/0xa0
el0_svc+0x1c/0x2c
el0_sync_handler+0xe8/0x114
el0_sync+0x180/0x1c0
[...]
==================================================================
To prevent the race above, revert back to taking the mmap write lock
inside binder_update_page_range(). One might expect an increase of mmap
lock contention. However, binder already serializes these calls via top
level alloc->mutex. Also, there was no performance impact shown when
running the binder benchmark tests.
Note this patch is specific to stable branches 5.4 and 5.10. Since in
newer kernel releases binder no longer caches a pointer to the vma.
Instead, it has been refactored to use vma_lookup() which avoids the
issue described here. This switch was introduced in commit a43cfc87caaf
("android: binder: stop saving a pointer to the VMA").
Fixes: dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap")
Reported-by: Jann Horn <jannh@google.com>
Cc: <stable@vger.kernel.org> # 5.4.x
Cc: Minchan Kim <minchan@kernel.org>
Cc: Yang Shi <yang.shi@linux.alibaba.com>
Cc: Liam Howlett <liam.howlett@oracle.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/android/binder_alloc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/android/binder_alloc.c
+++ b/drivers/android/binder_alloc.c
@@ -212,7 +212,7 @@ static int binder_update_page_range(stru
mm = alloc->vma_vm_mm;
if (mm) {
- down_read(&mm->mmap_sem);
+ down_write(&mm->mmap_sem);
vma = alloc->vma;
}
@@ -271,7 +271,7 @@ static int binder_update_page_range(stru
/* vm_insert_page does not seem to increment the refcount */
}
if (mm) {
- up_read(&mm->mmap_sem);
+ up_write(&mm->mmap_sem);
mmput(mm);
}
return 0;
@@ -304,7 +304,7 @@ err_page_ptr_cleared:
}
err_no_vma:
if (mm) {
- up_read(&mm->mmap_sem);
+ up_write(&mm->mmap_sem);
mmput(mm);
}
return vma ? -ENOMEM : -ESRCH;
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 48/74] btrfs: fix type of parameter generation in btrfs_get_dentry
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (46 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 47/74] binder: fix UAF of alloc->vma in race with munmap() Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 49/74] tcp/udp: Make early_demux back namespacified Greg Kroah-Hartman
` (32 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Josef Bacik, David Sterba
From: David Sterba <dsterba@suse.com>
commit 2398091f9c2c8e0040f4f9928666787a3e8108a7 upstream.
The type of parameter generation has been u32 since the beginning,
however all callers pass a u64 generation, so unify the types to prevent
potential loss.
CC: stable@vger.kernel.org # 4.9+
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/export.c | 2 +-
fs/btrfs/export.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/fs/btrfs/export.c
+++ b/fs/btrfs/export.c
@@ -58,7 +58,7 @@ static int btrfs_encode_fh(struct inode
}
struct dentry *btrfs_get_dentry(struct super_block *sb, u64 objectid,
- u64 root_objectid, u32 generation,
+ u64 root_objectid, u64 generation,
int check_generation)
{
struct btrfs_fs_info *fs_info = btrfs_sb(sb);
--- a/fs/btrfs/export.h
+++ b/fs/btrfs/export.h
@@ -19,7 +19,7 @@ struct btrfs_fid {
} __attribute__ ((packed));
struct dentry *btrfs_get_dentry(struct super_block *sb, u64 objectid,
- u64 root_objectid, u32 generation,
+ u64 root_objectid, u64 generation,
int check_generation);
struct dentry *btrfs_get_parent(struct dentry *child);
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 49/74] tcp/udp: Make early_demux back namespacified.
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (47 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 48/74] btrfs: fix type of parameter generation in btrfs_get_dentry Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 50/74] kprobe: reverse kp->flags when arm_kprobe failed Greg Kroah-Hartman
` (31 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Kuniyuki Iwashima, Jakub Kicinski
From: Kuniyuki Iwashima <kuniyu@amazon.com>
commit 11052589cf5c0bab3b4884d423d5f60c38fcf25d upstream.
Commit e21145a9871a ("ipv4: namespacify ip_early_demux sysctl knob") made
it possible to enable/disable early_demux on a per-netns basis. Then, we
introduced two knobs, tcp_early_demux and udp_early_demux, to switch it for
TCP/UDP in commit dddb64bcb346 ("net: Add sysctl to toggle early demux for
tcp and udp"). However, the .proc_handler() was wrong and actually
disabled us from changing the behaviour in each netns.
We can execute early_demux if net.ipv4.ip_early_demux is on and each proto
.early_demux() handler is not NULL. When we toggle (tcp|udp)_early_demux,
the change itself is saved in each netns variable, but the .early_demux()
handler is a global variable, so the handler is switched based on the
init_net's sysctl variable. Thus, netns (tcp|udp)_early_demux knobs have
nothing to do with the logic. Whether we CAN execute proto .early_demux()
is always decided by init_net's sysctl knob, and whether we DO it or not is
by each netns ip_early_demux knob.
This patch namespacifies (tcp|udp)_early_demux again. For now, the users
of the .early_demux() handler are TCP and UDP only, and they are called
directly to avoid retpoline. So, we can remove the .early_demux() handler
from inet6?_protos and need not dereference them in ip6?_rcv_finish_core().
If another proto needs .early_demux(), we can restore it at that time.
Fixes: dddb64bcb346 ("net: Add sysctl to toggle early demux for tcp and udp")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Link: https://lore.kernel.org/r/20220713175207.7727-1-kuniyu@amazon.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/net/protocol.h | 4 ---
include/net/tcp.h | 2 +
include/net/udp.h | 1
net/ipv4/af_inet.c | 14 +---------
net/ipv4/ip_input.c | 35 ++++++++++++++++----------
net/ipv4/sysctl_net_ipv4.c | 59 +--------------------------------------------
net/ipv6/ip6_input.c | 26 +++++++++++--------
net/ipv6/tcp_ipv6.c | 9 +-----
net/ipv6/udp.c | 9 +-----
9 files changed, 47 insertions(+), 112 deletions(-)
--- a/include/net/protocol.h
+++ b/include/net/protocol.h
@@ -35,8 +35,6 @@
/* This is used to register protocols. */
struct net_protocol {
- int (*early_demux)(struct sk_buff *skb);
- int (*early_demux_handler)(struct sk_buff *skb);
int (*handler)(struct sk_buff *skb);
/* This returns an error if we weren't able to handle the error. */
@@ -53,8 +51,6 @@ struct net_protocol {
#if IS_ENABLED(CONFIG_IPV6)
struct inet6_protocol {
- void (*early_demux)(struct sk_buff *skb);
- void (*early_demux_handler)(struct sk_buff *skb);
int (*handler)(struct sk_buff *skb);
/* This returns an error if we weren't able to handle the error. */
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -922,6 +922,8 @@ static inline int tcp_v6_sdif(const stru
#endif
return 0;
}
+
+void tcp_v6_early_demux(struct sk_buff *skb);
#endif
static inline bool inet_exact_dif_match(struct net *net, struct sk_buff *skb)
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -169,6 +169,7 @@ typedef struct sock *(*udp_lookup_t)(str
struct sk_buff *udp_gro_receive(struct list_head *head, struct sk_buff *skb,
struct udphdr *uh, udp_lookup_t lookup);
int udp_gro_complete(struct sk_buff *skb, int nhoff, udp_lookup_t lookup);
+void udp_v6_early_demux(struct sk_buff *skb);
struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
netdev_features_t features);
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1702,12 +1702,7 @@ static const struct net_protocol igmp_pr
};
#endif
-/* thinking of making this const? Don't.
- * early_demux can change based on sysctl.
- */
-static struct net_protocol tcp_protocol = {
- .early_demux = tcp_v4_early_demux,
- .early_demux_handler = tcp_v4_early_demux,
+static const struct net_protocol tcp_protocol = {
.handler = tcp_v4_rcv,
.err_handler = tcp_v4_err,
.no_policy = 1,
@@ -1715,12 +1710,7 @@ static struct net_protocol tcp_protocol
.icmp_strict_tag_validation = 1,
};
-/* thinking of making this const? Don't.
- * early_demux can change based on sysctl.
- */
-static struct net_protocol udp_protocol = {
- .early_demux = udp_v4_early_demux,
- .early_demux_handler = udp_v4_early_demux,
+static const struct net_protocol udp_protocol = {
.handler = udp_rcv,
.err_handler = udp_err,
.no_policy = 1,
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -302,31 +302,38 @@ drop:
return true;
}
-INDIRECT_CALLABLE_DECLARE(int udp_v4_early_demux(struct sk_buff *));
-INDIRECT_CALLABLE_DECLARE(int tcp_v4_early_demux(struct sk_buff *));
+int udp_v4_early_demux(struct sk_buff *);
+int tcp_v4_early_demux(struct sk_buff *);
static int ip_rcv_finish_core(struct net *net, struct sock *sk,
struct sk_buff *skb, struct net_device *dev)
{
const struct iphdr *iph = ip_hdr(skb);
- int (*edemux)(struct sk_buff *skb);
struct rtable *rt;
int err;
- if (net->ipv4.sysctl_ip_early_demux &&
+ if (READ_ONCE(net->ipv4.sysctl_ip_early_demux) &&
!skb_dst(skb) &&
!skb->sk &&
!ip_is_fragment(iph)) {
- const struct net_protocol *ipprot;
- int protocol = iph->protocol;
+ switch (iph->protocol) {
+ case IPPROTO_TCP:
+ if (READ_ONCE(net->ipv4.sysctl_tcp_early_demux)) {
+ tcp_v4_early_demux(skb);
- ipprot = rcu_dereference(inet_protos[protocol]);
- if (ipprot && (edemux = READ_ONCE(ipprot->early_demux))) {
- err = INDIRECT_CALL_2(edemux, tcp_v4_early_demux,
- udp_v4_early_demux, skb);
- if (unlikely(err))
- goto drop_error;
- /* must reload iph, skb->head might have changed */
- iph = ip_hdr(skb);
+ /* must reload iph, skb->head might have changed */
+ iph = ip_hdr(skb);
+ }
+ break;
+ case IPPROTO_UDP:
+ if (READ_ONCE(net->ipv4.sysctl_udp_early_demux)) {
+ err = udp_v4_early_demux(skb);
+ if (unlikely(err))
+ goto drop_error;
+
+ /* must reload iph, skb->head might have changed */
+ iph = ip_hdr(skb);
+ }
+ break;
}
}
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -363,61 +363,6 @@ bad_key:
return ret;
}
-static void proc_configure_early_demux(int enabled, int protocol)
-{
- struct net_protocol *ipprot;
-#if IS_ENABLED(CONFIG_IPV6)
- struct inet6_protocol *ip6prot;
-#endif
-
- rcu_read_lock();
-
- ipprot = rcu_dereference(inet_protos[protocol]);
- if (ipprot)
- ipprot->early_demux = enabled ? ipprot->early_demux_handler :
- NULL;
-
-#if IS_ENABLED(CONFIG_IPV6)
- ip6prot = rcu_dereference(inet6_protos[protocol]);
- if (ip6prot)
- ip6prot->early_demux = enabled ? ip6prot->early_demux_handler :
- NULL;
-#endif
- rcu_read_unlock();
-}
-
-static int proc_tcp_early_demux(struct ctl_table *table, int write,
- void __user *buffer, size_t *lenp, loff_t *ppos)
-{
- int ret = 0;
-
- ret = proc_dointvec(table, write, buffer, lenp, ppos);
-
- if (write && !ret) {
- int enabled = init_net.ipv4.sysctl_tcp_early_demux;
-
- proc_configure_early_demux(enabled, IPPROTO_TCP);
- }
-
- return ret;
-}
-
-static int proc_udp_early_demux(struct ctl_table *table, int write,
- void __user *buffer, size_t *lenp, loff_t *ppos)
-{
- int ret = 0;
-
- ret = proc_dointvec(table, write, buffer, lenp, ppos);
-
- if (write && !ret) {
- int enabled = init_net.ipv4.sysctl_udp_early_demux;
-
- proc_configure_early_demux(enabled, IPPROTO_UDP);
- }
-
- return ret;
-}
-
static int proc_tfo_blackhole_detect_timeout(struct ctl_table *table,
int write,
void __user *buffer,
@@ -701,14 +646,14 @@ static struct ctl_table ipv4_net_table[]
.data = &init_net.ipv4.sysctl_udp_early_demux,
.maxlen = sizeof(int),
.mode = 0644,
- .proc_handler = proc_udp_early_demux
+ .proc_handler = proc_douintvec_minmax,
},
{
.procname = "tcp_early_demux",
.data = &init_net.ipv4.sysctl_tcp_early_demux,
.maxlen = sizeof(int),
.mode = 0644,
- .proc_handler = proc_tcp_early_demux
+ .proc_handler = proc_douintvec_minmax,
},
{
.procname = "ip_default_ttl",
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -44,21 +44,25 @@
#include <net/inet_ecn.h>
#include <net/dst_metadata.h>
-INDIRECT_CALLABLE_DECLARE(void udp_v6_early_demux(struct sk_buff *));
-INDIRECT_CALLABLE_DECLARE(void tcp_v6_early_demux(struct sk_buff *));
+void udp_v6_early_demux(struct sk_buff *);
+void tcp_v6_early_demux(struct sk_buff *);
static void ip6_rcv_finish_core(struct net *net, struct sock *sk,
struct sk_buff *skb)
{
- void (*edemux)(struct sk_buff *skb);
-
- if (net->ipv4.sysctl_ip_early_demux && !skb_dst(skb) && skb->sk == NULL) {
- const struct inet6_protocol *ipprot;
-
- ipprot = rcu_dereference(inet6_protos[ipv6_hdr(skb)->nexthdr]);
- if (ipprot && (edemux = READ_ONCE(ipprot->early_demux)))
- INDIRECT_CALL_2(edemux, tcp_v6_early_demux,
- udp_v6_early_demux, skb);
+ if (READ_ONCE(net->ipv4.sysctl_ip_early_demux) &&
+ !skb_dst(skb) && !skb->sk) {
+ switch (ipv6_hdr(skb)->nexthdr) {
+ case IPPROTO_TCP:
+ if (READ_ONCE(net->ipv4.sysctl_tcp_early_demux))
+ tcp_v6_early_demux(skb);
+ break;
+ case IPPROTO_UDP:
+ if (READ_ONCE(net->ipv4.sysctl_udp_early_demux))
+ udp_v6_early_demux(skb);
+ break;
+ }
}
+
if (!skb_valid_dst(skb))
ip6_route_input(skb);
}
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1729,7 +1729,7 @@ do_time_wait:
goto discard_it;
}
-INDIRECT_CALLABLE_SCOPE void tcp_v6_early_demux(struct sk_buff *skb)
+void tcp_v6_early_demux(struct sk_buff *skb)
{
const struct ipv6hdr *hdr;
const struct tcphdr *th;
@@ -2084,12 +2084,7 @@ struct proto tcpv6_prot = {
.diag_destroy = tcp_abort,
};
-/* thinking of making this const? Don't.
- * early_demux can change based on sysctl.
- */
-static struct inet6_protocol tcpv6_protocol = {
- .early_demux = tcp_v6_early_demux,
- .early_demux_handler = tcp_v6_early_demux,
+static const struct inet6_protocol tcpv6_protocol = {
.handler = tcp_v6_rcv,
.err_handler = tcp_v6_err,
.flags = INET6_PROTO_NOPOLICY|INET6_PROTO_FINAL,
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -973,7 +973,7 @@ static struct sock *__udp6_lib_demux_loo
return NULL;
}
-INDIRECT_CALLABLE_SCOPE void udp_v6_early_demux(struct sk_buff *skb)
+void udp_v6_early_demux(struct sk_buff *skb)
{
struct net *net = dev_net(skb->dev);
const struct udphdr *uh;
@@ -1603,12 +1603,7 @@ int compat_udpv6_getsockopt(struct sock
}
#endif
-/* thinking of making this const? Don't.
- * early_demux can change based on sysctl.
- */
-static struct inet6_protocol udpv6_protocol = {
- .early_demux = udp_v6_early_demux,
- .early_demux_handler = udp_v6_early_demux,
+static const struct inet6_protocol udpv6_protocol = {
.handler = udpv6_rcv,
.err_handler = udpv6_err,
.flags = INET6_PROTO_NOPOLICY|INET6_PROTO_FINAL,
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 50/74] kprobe: reverse kp->flags when arm_kprobe failed
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (48 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 49/74] tcp/udp: Make early_demux back namespacified Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 51/74] tools/nolibc/string: Fix memcmp() implementation Greg Kroah-Hartman
` (30 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Li Qiang, Masami Hiramatsu (Google)
From: Li Qiang <liq3ea@163.com>
commit 4a6f316d6855a434f56dbbeba05e14c01acde8f8 upstream.
In aggregate kprobe case, when arm_kprobe failed,
we need set the kp->flags with KPROBE_FLAG_DISABLED again.
If not, the 'kp' kprobe will been considered as enabled
but it actually not enabled.
Link: https://lore.kernel.org/all/20220902155820.34755-1-liq3ea@163.com/
Fixes: 12310e343755 ("kprobes: Propagate error from arm_kprobe_ftrace()")
Cc: stable@vger.kernel.org
Signed-off-by: Li Qiang <liq3ea@163.com>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/kprobes.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2199,8 +2199,11 @@ int enable_kprobe(struct kprobe *kp)
if (!kprobes_all_disarmed && kprobe_disabled(p)) {
p->flags &= ~KPROBE_FLAG_DISABLED;
ret = arm_kprobe(p);
- if (ret)
+ if (ret) {
p->flags |= KPROBE_FLAG_DISABLED;
+ if (p != kp)
+ kp->flags |= KPROBE_FLAG_DISABLED;
+ }
}
out:
mutex_unlock(&kprobe_mutex);
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 51/74] tools/nolibc/string: Fix memcmp() implementation
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (49 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 50/74] kprobe: reverse kp->flags when arm_kprobe failed Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 52/74] tracing/histogram: Update document for KEYS_MAX size Greg Kroah-Hartman
` (29 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Rasmus Villemoes, Willy Tarreau,
Paul E. McKenney
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
commit b3f4f51ea68a495f8a5956064c33dce711a2df91 upstream.
The C standard says that memcmp() must treat the buffers as consisting
of "unsigned chars". If char happens to be unsigned, the casts are ok,
but then obviously the c1 variable can never contain a negative
value. And when char is signed, the casts are wrong, and there's still
a problem with using an 8-bit quantity to hold the difference, because
that can range from -255 to +255.
For example, assuming char is signed, comparing two 1-byte buffers,
one containing 0x00 and another 0x80, the current implementation would
return -128 for both memcmp(a, b, 1) and memcmp(b, a, 1), whereas one
of those should of course return something positive.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Fixes: 66b6f755ad45 ("rcutorture: Import a copy of nolibc")
Cc: stable@vger.kernel.org # v5.0+
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/include/nolibc/nolibc.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/tools/include/nolibc/nolibc.h
+++ b/tools/include/nolibc/nolibc.h
@@ -2318,9 +2318,9 @@ static __attribute__((unused))
int memcmp(const void *s1, const void *s2, size_t n)
{
size_t ofs = 0;
- char c1 = 0;
+ int c1 = 0;
- while (ofs < n && !(c1 = ((char *)s1)[ofs] - ((char *)s2)[ofs])) {
+ while (ofs < n && !(c1 = ((unsigned char *)s1)[ofs] - ((unsigned char *)s2)[ofs])) {
ofs++;
}
return c1;
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 52/74] tracing/histogram: Update document for KEYS_MAX size
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (50 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 51/74] tools/nolibc/string: Fix memcmp() implementation Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 53/74] capabilities: fix potential memleak on error path from vfs_getxattr_alloc() Greg Kroah-Hartman
` (28 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Zheng Yejian,
Masami Hiramatsu (Google),
Jonathan Corbet
From: Zheng Yejian <zhengyejian1@huawei.com>
commit a635beeacc6d56d2b71c39e6c0103f85b53d108e upstream.
After commit 4f36c2d85ced ("tracing: Increase tracing map KEYS_MAX size"),
'keys' supports up to three fields.
Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
Cc: stable@vger.kernel.org
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Link: https://lore.kernel.org/r/20221017103806.2479139-1-zhengyejian1@huawei.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/trace/histogram.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/Documentation/trace/histogram.rst
+++ b/Documentation/trace/histogram.rst
@@ -39,7 +39,7 @@ Documentation written by Tom Zanussi
will use the event's kernel stacktrace as the key. The keywords
'keys' or 'key' can be used to specify keys, and the keywords
'values', 'vals', or 'val' can be used to specify values. Compound
- keys consisting of up to two fields can be specified by the 'keys'
+ keys consisting of up to three fields can be specified by the 'keys'
keyword. Hashing a compound key produces a unique entry in the
table for each unique combination of component keys, and can be
useful for providing more fine-grained summaries of event data.
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 53/74] capabilities: fix potential memleak on error path from vfs_getxattr_alloc()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (51 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 52/74] tracing/histogram: Update document for KEYS_MAX size Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 54/74] fuse: add file_modified() to fallocate Greg Kroah-Hartman
` (27 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Gaosheng Cui, Serge Hallyn, Paul Moore
From: Gaosheng Cui <cuigaosheng1@huawei.com>
commit 8cf0a1bc12870d148ae830a4ba88cfdf0e879cee upstream.
In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to
complete the memory allocation of tmpbuf, if we have completed
the memory allocation of tmpbuf, but failed to call handler->get(...),
there will be a memleak in below logic:
|-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...)
| /* ^^^ alloc for tmpbuf */
|-- value = krealloc(*xattr_value, error + 1, flags)
| /* ^^^ alloc memory */
|-- error = handler->get(handler, ...)
| /* error! */
|-- *xattr_value = value
| /* xattr_value is &tmpbuf (memory leak!) */
So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it.
Cc: stable@vger.kernel.org
Fixes: 8db6c34f1dbc ("Introduce v3 namespaced file capabilities")
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
Acked-by: Serge Hallyn <serge@hallyn.com>
[PM: subject line and backtrace tweaks]
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
security/commoncap.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -391,8 +391,10 @@ int cap_inode_getsecurity(struct inode *
&tmpbuf, size, GFP_NOFS);
dput(dentry);
- if (ret < 0 || !tmpbuf)
- return ret;
+ if (ret < 0 || !tmpbuf) {
+ size = ret;
+ goto out_free;
+ }
fs_ns = inode->i_sb->s_user_ns;
cap = (struct vfs_cap_data *) tmpbuf;
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 54/74] fuse: add file_modified() to fallocate
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (52 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 53/74] capabilities: fix potential memleak on error path from vfs_getxattr_alloc() Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 55/74] efi: random: reduce seed size to 32 bytes Greg Kroah-Hartman
` (26 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Miklos Szeredi
From: Miklos Szeredi <mszeredi@redhat.com>
commit 4a6f278d4827b59ba26ceae0ff4529ee826aa258 upstream.
Add missing file_modified() call to fuse_file_fallocate(). Without this
fallocate on fuse failed to clear privileges.
Fixes: 05ba1f082300 ("fuse: add FALLOCATE operation")
Cc: <stable@vger.kernel.org>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/fuse/file.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -3239,6 +3239,10 @@ static long fuse_file_fallocate(struct f
goto out;
}
+ err = file_modified(file);
+ if (err)
+ goto out;
+
if (!(mode & FALLOC_FL_KEEP_SIZE))
set_bit(FUSE_I_SIZE_UNSTABLE, &fi->state);
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 55/74] efi: random: reduce seed size to 32 bytes
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (53 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 54/74] fuse: add file_modified() to fallocate Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 56/74] perf/x86/intel: Fix pebs event constraints for ICL Greg Kroah-Hartman
` (25 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Ard Biesheuvel, Jason A. Donenfeld,
Ilias Apalodimas
From: Ard Biesheuvel <ardb@kernel.org>
commit 161a438d730dade2ba2b1bf8785f0759aba4ca5f upstream.
We no longer need at least 64 bytes of random seed to permit the early
crng init to complete. The RNG is now based on Blake2s, so reduce the
EFI seed size to the Blake2s hash size, which is sufficient for our
purposes.
While at it, drop the READ_ONCE(), which was supposed to prevent size
from being evaluated after seed was unmapped. However, this cannot
actually happen, so READ_ONCE() is unnecessary here.
Cc: <stable@vger.kernel.org> # v4.14+
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firmware/efi/efi.c | 2 +-
include/linux/efi.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -546,7 +546,7 @@ int __init efi_config_parse_tables(void
seed = early_memremap(efi.rng_seed, sizeof(*seed));
if (seed != NULL) {
- size = READ_ONCE(seed->size);
+ size = min(seed->size, EFI_RANDOM_SEED_SIZE);
early_memunmap(seed, sizeof(*seed));
} else {
pr_err("Could not map UEFI random seed!\n");
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1715,7 +1715,7 @@ efi_status_t efi_exit_boot_services(efi_
void *priv,
efi_exit_boot_map_processing priv_func);
-#define EFI_RANDOM_SEED_SIZE 64U
+#define EFI_RANDOM_SEED_SIZE 32U // BLAKE2S_HASH_SIZE
struct linux_efi_random_seed {
u32 size;
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 56/74] perf/x86/intel: Fix pebs event constraints for ICL
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (54 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 55/74] efi: random: reduce seed size to 32 bytes Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 57/74] perf/x86/intel: Add Cooper Lake stepping to isolation_ucodes[] Greg Kroah-Hartman
` (24 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Jannis Klinkenberg, Kan Liang,
Peter Zijlstra (Intel)
From: Kan Liang <kan.liang@linux.intel.com>
commit acc5568b90c19ac6375508a93b9676cd18a92a35 upstream.
According to the latest event list, update the MEM_INST_RETIRED events
which support the DataLA facility.
Fixes: 6017608936c1 ("perf/x86/intel: Add Icelake support")
Reported-by: Jannis Klinkenberg <jannis.klinkenberg@rwth-aachen.de>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20221031154119.571386-1-kan.liang@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/events/intel/ds.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -852,8 +852,13 @@ struct event_constraint intel_icl_pebs_e
INTEL_FLAGS_UEVENT_CONSTRAINT(0x0400, 0x800000000ULL), /* SLOTS */
INTEL_PLD_CONSTRAINT(0x1cd, 0xff), /* MEM_TRANS_RETIRED.LOAD_LATENCY */
- INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_LD(0x1d0, 0xf), /* MEM_INST_RETIRED.LOAD */
- INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_ST(0x2d0, 0xf), /* MEM_INST_RETIRED.STORE */
+ INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_LD(0x11d0, 0xf), /* MEM_INST_RETIRED.STLB_MISS_LOADS */
+ INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_ST(0x12d0, 0xf), /* MEM_INST_RETIRED.STLB_MISS_STORES */
+ INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_LD(0x21d0, 0xf), /* MEM_INST_RETIRED.LOCK_LOADS */
+ INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_LD(0x41d0, 0xf), /* MEM_INST_RETIRED.SPLIT_LOADS */
+ INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_ST(0x42d0, 0xf), /* MEM_INST_RETIRED.SPLIT_STORES */
+ INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_LD(0x81d0, 0xf), /* MEM_INST_RETIRED.ALL_LOADS */
+ INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_ST(0x82d0, 0xf), /* MEM_INST_RETIRED.ALL_STORES */
INTEL_FLAGS_EVENT_CONSTRAINT_DATALA_LD_RANGE(0xd1, 0xd4, 0xf), /* MEM_LOAD_*_RETIRED.* */
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 57/74] perf/x86/intel: Add Cooper Lake stepping to isolation_ucodes[]
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (55 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 56/74] perf/x86/intel: Fix pebs event constraints for ICL Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 58/74] ALSA: usb-audio: Add quirks for MacroSilicon MS2100/MS2106 devices Greg Kroah-Hartman
` (23 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Kan Liang, Peter Zijlstra (Intel)
From: Kan Liang <kan.liang@linux.intel.com>
commit 6f8faf471446844bb9c318e0340221049d5c19f4 upstream.
The intel_pebs_isolation quirk checks both model number and stepping.
Cooper Lake has a different stepping (11) than the other Skylake Xeon.
It cannot benefit from the optimization in commit 9b545c04abd4f
("perf/x86/kvm: Avoid unnecessary work in guest filtering").
Add the stepping of Cooper Lake into the isolation_ucodes[] table.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20221031154550.571663-1-kan.liang@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/events/intel/core.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -4009,6 +4009,7 @@ static const struct x86_cpu_desc isolati
INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_X, 5, 0x00000000),
INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_X, 6, 0x00000000),
INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_X, 7, 0x00000000),
+ INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_X, 11, 0x00000000),
INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_L, 3, 0x0000007c),
INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE, 3, 0x0000007c),
INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE, 9, 0x0000004e),
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 58/74] ALSA: usb-audio: Add quirks for MacroSilicon MS2100/MS2106 devices
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (56 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 57/74] perf/x86/intel: Add Cooper Lake stepping to isolation_ucodes[] Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 59/74] parisc: Make 8250_gsc driver dependend on CONFIG_PARISC Greg Kroah-Hartman
` (22 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, John Veness, Takashi Iwai
From: John Veness <john-linux@pelago.org.uk>
commit 6e2c9105e0b743c92a157389d40f00b81bdd09fe upstream.
Treat the claimed 96kHz 1ch in the descriptors as 48kHz 2ch, so that
the audio stream doesn't sound mono. Also fix initial stream
alignment, so that left and right channels are in the correct order.
Signed-off-by: John Veness <john-linux@pelago.org.uk>
Link: https://lore.kernel.org/r/20220624140757.28758-1-john-linux@pelago.org.uk
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/usb/quirks-table.h | 58 +++++++++++++++++++++++++++++++++++++++++++++++
sound/usb/quirks.c | 1
2 files changed, 59 insertions(+)
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -3760,6 +3760,64 @@ ALC1220_VB_DESKTOP(0x26ce, 0x0a01), /* A
},
/*
+ * MacroSilicon MS2100/MS2106 based AV capture cards
+ *
+ * These claim 96kHz 1ch in the descriptors, but are actually 48kHz 2ch.
+ * They also need QUIRK_AUDIO_ALIGN_TRANSFER, which makes one wonder if
+ * they pretend to be 96kHz mono as a workaround for stereo being broken
+ * by that...
+ *
+ * They also have an issue with initial stream alignment that causes the
+ * channels to be swapped and out of phase, which is dealt with in quirks.c.
+ */
+{
+ .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
+ USB_DEVICE_ID_MATCH_INT_CLASS |
+ USB_DEVICE_ID_MATCH_INT_SUBCLASS,
+ .idVendor = 0x534d,
+ .idProduct = 0x0021,
+ .bInterfaceClass = USB_CLASS_AUDIO,
+ .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL,
+ .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) {
+ .vendor_name = "MacroSilicon",
+ .product_name = "MS210x",
+ .ifnum = QUIRK_ANY_INTERFACE,
+ .type = QUIRK_COMPOSITE,
+ .data = &(const struct snd_usb_audio_quirk[]) {
+ {
+ .ifnum = 2,
+ .type = QUIRK_AUDIO_ALIGN_TRANSFER,
+ },
+ {
+ .ifnum = 2,
+ .type = QUIRK_AUDIO_STANDARD_MIXER,
+ },
+ {
+ .ifnum = 3,
+ .type = QUIRK_AUDIO_FIXED_ENDPOINT,
+ .data = &(const struct audioformat) {
+ .formats = SNDRV_PCM_FMTBIT_S16_LE,
+ .channels = 2,
+ .iface = 3,
+ .altsetting = 1,
+ .altset_idx = 1,
+ .attributes = 0,
+ .endpoint = 0x82,
+ .ep_attr = USB_ENDPOINT_XFER_ISOC |
+ USB_ENDPOINT_SYNC_ASYNC,
+ .rates = SNDRV_PCM_RATE_CONTINUOUS,
+ .rate_min = 48000,
+ .rate_max = 48000,
+ }
+ },
+ {
+ .ifnum = -1
+ }
+ }
+ }
+},
+
+/*
* MacroSilicon MS2109 based HDMI capture cards
*
* These claim 96kHz 1ch in the descriptors, but are actually 48kHz 2ch.
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1440,6 +1440,7 @@ void snd_usb_set_format_quirk(struct snd
case USB_ID(0x041e, 0x3f19): /* E-Mu 0204 USB */
set_format_emu_quirk(subs, fmt);
break;
+ case USB_ID(0x534d, 0x0021): /* MacroSilicon MS2100/MS2106 */
case USB_ID(0x534d, 0x2109): /* MacroSilicon MS2109 */
subs->stream_offset_adj = 2;
break;
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 59/74] parisc: Make 8250_gsc driver dependend on CONFIG_PARISC
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (57 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 58/74] ALSA: usb-audio: Add quirks for MacroSilicon MS2100/MS2106 devices Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 60/74] parisc: Export iosapic_serial_irq() symbol for serial port driver Greg Kroah-Hartman
` (21 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Mikulas Patocka, Helge Deller
From: Helge Deller <deller@gmx.de>
commit e8a18e3f00f3ee8d07c17ab1ea3ad4df4a3b6fe0 upstream.
Although the name of the driver 8250_gsc.c suggests that it handles
only serial ports on the GSC bus, it does handle serial ports listed
in the parisc machine inventory as well, e.g. the serial ports in a
C8000 PCI-only workstation.
Change the dependency to CONFIG_PARISC, so that the driver gets included
in the kernel even if CONFIG_GSC isn't set.
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/8250/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -108,7 +108,7 @@ config SERIAL_8250_CONSOLE
config SERIAL_8250_GSC
tristate
- depends on SERIAL_8250 && GSC
+ depends on SERIAL_8250 && PARISC
default SERIAL_8250
config SERIAL_8250_DMA
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 60/74] parisc: Export iosapic_serial_irq() symbol for serial port driver
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (58 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 59/74] parisc: Make 8250_gsc driver dependend on CONFIG_PARISC Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 61/74] parisc: Avoid printing the hardware path twice Greg Kroah-Hartman
` (20 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Helge Deller, kernel test robot
From: Helge Deller <deller@gmx.de>
commit a0c9f1f2e53b8eb2ae43987a30e547ba56b4fa18 upstream.
The parisc serial port driver needs this symbol when it's compiled
as module.
Signed-off-by: Helge Deller <deller@gmx.de>
Reported-by: kernel test robot <lkp@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/parisc/iosapic.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/parisc/iosapic.c
+++ b/drivers/parisc/iosapic.c
@@ -875,6 +875,7 @@ int iosapic_serial_irq(struct parisc_dev
return vi->txn_irq;
}
+EXPORT_SYMBOL(iosapic_serial_irq);
#endif
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 61/74] parisc: Avoid printing the hardware path twice
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (59 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 60/74] parisc: Export iosapic_serial_irq() symbol for serial port driver Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 62/74] ext4: fix warning in ext4_da_release_space Greg Kroah-Hartman
` (19 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Helge Deller
From: Helge Deller <deller@gmx.de>
commit 2b6ae0962b421103feb41a80406732944b0665b3 upstream.
Avoid that the hardware path is shown twice in the kernel log, and clean
up the output of the version numbers to show up in the same order as
they are listed in the hardware database in the hardware.c file.
Additionally, optimize the memory footprint of the hardware database
and mark some code as init code.
Fixes: cab56b51ec0e ("parisc: Fix device names in /proc/iomem")
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: <stable@vger.kernel.org> # v4.9+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/parisc/include/asm/hardware.h | 12 ++++++------
arch/parisc/kernel/drivers.c | 14 ++++++--------
2 files changed, 12 insertions(+), 14 deletions(-)
--- a/arch/parisc/include/asm/hardware.h
+++ b/arch/parisc/include/asm/hardware.h
@@ -10,12 +10,12 @@
#define SVERSION_ANY_ID PA_SVERSION_ANY_ID
struct hp_hardware {
- unsigned short hw_type:5; /* HPHW_xxx */
- unsigned short hversion;
- unsigned long sversion:28;
- unsigned short opt;
- const char name[80]; /* The hardware description */
-};
+ unsigned int hw_type:8; /* HPHW_xxx */
+ unsigned int hversion:12;
+ unsigned int sversion:12;
+ unsigned char opt;
+ unsigned char name[59]; /* The hardware description */
+} __packed;
struct parisc_device;
--- a/arch/parisc/kernel/drivers.c
+++ b/arch/parisc/kernel/drivers.c
@@ -882,15 +882,13 @@ void __init walk_central_bus(void)
&root);
}
-static void print_parisc_device(struct parisc_device *dev)
+static __init void print_parisc_device(struct parisc_device *dev)
{
- char hw_path[64];
- static int count;
+ static int count __initdata;
- print_pa_hwpath(dev, hw_path);
- pr_info("%d. %s at %pap [%s] { %d, 0x%x, 0x%.3x, 0x%.5x }",
- ++count, dev->name, &(dev->hpa.start), hw_path, dev->id.hw_type,
- dev->id.hversion_rev, dev->id.hversion, dev->id.sversion);
+ pr_info("%d. %s at %pap { type:%d, hv:%#x, sv:%#x, rev:%#x }",
+ ++count, dev->name, &(dev->hpa.start), dev->id.hw_type,
+ dev->id.hversion, dev->id.sversion, dev->id.hversion_rev);
if (dev->num_addrs) {
int k;
@@ -1079,7 +1077,7 @@ static __init int qemu_print_iodc_data(s
-static int print_one_device(struct device * dev, void * data)
+static __init int print_one_device(struct device * dev, void * data)
{
struct parisc_device * pdev = to_parisc_device(dev);
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 62/74] ext4: fix warning in ext4_da_release_space
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (60 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 61/74] parisc: Avoid printing the hardware path twice Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 63/74] ext4: fix BUG_ON() when directory entry has invalid rec_len Greg Kroah-Hartman
` (18 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, syzbot+c740bb18df70ad00952e,
Ye Bin, Jan Kara, Theodore Tso
From: Ye Bin <yebin10@huawei.com>
commit 1b8f787ef547230a3249bcf897221ef0cc78481b upstream.
Syzkaller report issue as follows:
EXT4-fs (loop0): Free/Dirty block details
EXT4-fs (loop0): free_blocks=0
EXT4-fs (loop0): dirty_blocks=0
EXT4-fs (loop0): Block reservation details
EXT4-fs (loop0): i_reserved_data_blocks=0
EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks
------------[ cut here ]------------
WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524
Modules linked in:
CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: writeback wb_workfn (flush-7:0)
RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528
RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296
RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00
RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000
RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5
R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000
R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740
FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461
mpage_release_unused_pages+0x24d/0xef0 fs/ext4/inode.c:1589
ext4_writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852
do_writepages+0x3c3/0x680 mm/page-writeback.c:2469
__writeback_single_inode+0xd1/0x670 fs/fs-writeback.c:1587
writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1870
wb_writeback+0x41f/0x7b0 fs/fs-writeback.c:2044
wb_do_writeback fs/fs-writeback.c:2187 [inline]
wb_workfn+0x3cb/0xef0 fs/fs-writeback.c:2227
process_one_work+0x877/0xdb0 kernel/workqueue.c:2289
worker_thread+0xb14/0x1330 kernel/workqueue.c:2436
kthread+0x266/0x300 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
</TASK>
Above issue may happens as follows:
ext4_da_write_begin
ext4_create_inline_data
ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS);
ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA);
__ext4_ioctl
ext4_ext_migrate -> will lead to eh->eh_entries not zero, and set extent flag
ext4_da_write_begin
ext4_da_convert_inline_data_to_extent
ext4_da_write_inline_data_begin
ext4_da_map_blocks
ext4_insert_delayed_block
if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk))
if (!ext4_es_scan_clu(inode, &ext4_es_is_mapped, lblk))
ext4_clu_mapped(inode, EXT4_B2C(sbi, lblk)); -> will return 1
allocated = true;
ext4_es_insert_delayed_block(inode, lblk, allocated);
ext4_writepages
mpage_map_and_submit_extent(handle, &mpd, &give_up_on_write); -> return -ENOSPC
mpage_release_unused_pages(&mpd, give_up_on_write); -> give_up_on_write == 1
ext4_es_remove_extent
ext4_da_release_space(inode, reserved);
if (unlikely(to_free > ei->i_reserved_data_blocks))
-> to_free == 1 but ei->i_reserved_data_blocks == 0
-> then trigger warning as above
To solve above issue, forbid inode do migrate which has inline data.
Cc: stable@kernel.org
Reported-by: syzbot+c740bb18df70ad00952e@syzkaller.appspotmail.com
Signed-off-by: Ye Bin <yebin10@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20221018022701.683489-1-yebin10@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/migrate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/ext4/migrate.c
+++ b/fs/ext4/migrate.c
@@ -443,7 +443,8 @@ int ext4_ext_migrate(struct inode *inode
* already is extent-based, error out.
*/
if (!ext4_has_feature_extents(inode->i_sb) ||
- (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)))
+ ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS) ||
+ ext4_has_inline_data(inode))
return -EINVAL;
if (S_ISLNK(inode->i_mode) && inode->i_blocks == 0)
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 63/74] ext4: fix BUG_ON() when directory entry has invalid rec_len
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (61 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 62/74] ext4: fix warning in ext4_da_release_space Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 64/74] KVM: x86: Mask off reserved bits in CPUID.8000001AH Greg Kroah-Hartman
` (17 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Luís Henriques, Theodore Tso
From: Luís Henriques <lhenriques@suse.de>
commit 17a0bc9bd697f75cfdf9b378d5eb2d7409c91340 upstream.
The rec_len field in the directory entry has to be a multiple of 4. A
corrupted filesystem image can be used to hit a BUG() in
ext4_rec_len_to_disk(), called from make_indexed_dir().
------------[ cut here ]------------
kernel BUG at fs/ext4/ext4.h:2413!
...
RIP: 0010:make_indexed_dir+0x53f/0x5f0
...
Call Trace:
<TASK>
? add_dirent_to_buf+0x1b2/0x200
ext4_add_entry+0x36e/0x480
ext4_add_nondir+0x2b/0xc0
ext4_create+0x163/0x200
path_openat+0x635/0xe90
do_filp_open+0xb4/0x160
? __create_object.isra.0+0x1de/0x3b0
? _raw_spin_unlock+0x12/0x30
do_sys_openat2+0x91/0x150
__x64_sys_open+0x6c/0xa0
do_syscall_64+0x3c/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
The fix simply adds a call to ext4_check_dir_entry() to validate the
directory entry, returning -EFSCORRUPTED if the entry is invalid.
CC: stable@kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216540
Signed-off-by: Luís Henriques <lhenriques@suse.de>
Link: https://lore.kernel.org/r/20221012131330.32456-1-lhenriques@suse.de
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/namei.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -2141,8 +2141,16 @@ static int make_indexed_dir(handle_t *ha
memcpy(data2, de, len);
de = (struct ext4_dir_entry_2 *) data2;
top = data2 + len;
- while ((char *)(de2 = ext4_next_entry(de, blocksize)) < top)
+ while ((char *)(de2 = ext4_next_entry(de, blocksize)) < top) {
+ if (ext4_check_dir_entry(dir, NULL, de, bh2, data2, len,
+ (data2 + (blocksize - csum_size) -
+ (char *) de))) {
+ brelse(bh2);
+ brelse(bh);
+ return -EFSCORRUPTED;
+ }
de = de2;
+ }
de->rec_len = ext4_rec_len_to_disk(data2 + (blocksize - csum_size) -
(char *) de, blocksize);
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 64/74] KVM: x86: Mask off reserved bits in CPUID.8000001AH
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (62 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 63/74] ext4: fix BUG_ON() when directory entry has invalid rec_len Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 65/74] KVM: x86: Mask off reserved bits in CPUID.80000008H Greg Kroah-Hartman
` (16 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Jim Mattson, Paolo Bonzini
From: Jim Mattson <jmattson@google.com>
commit 079f6889818dd07903fb36c252532ab47ebb6d48 upstream.
KVM_GET_SUPPORTED_CPUID should only enumerate features that KVM
actually supports. In the case of CPUID.8000001AH, only three bits are
currently defined. The 125 reserved bits should be masked off.
Fixes: 24c82e576b78 ("KVM: Sanitize cpuid")
Signed-off-by: Jim Mattson <jmattson@google.com>
Message-Id: <20220929225203.2234702-4-jmattson@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/cpuid.c | 3 +++
1 file changed, 3 insertions(+)
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -791,6 +791,9 @@ static inline int __do_cpuid_func(struct
entry->ecx = entry->edx = 0;
break;
case 0x8000001a:
+ entry->eax &= GENMASK(2, 0);
+ entry->ebx = entry->ecx = entry->edx = 0;
+ break;
case 0x8000001e:
break;
/*Add support for Centaur's CPUID instruction*/
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 65/74] KVM: x86: Mask off reserved bits in CPUID.80000008H
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (63 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 64/74] KVM: x86: Mask off reserved bits in CPUID.8000001AH Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 66/74] KVM: x86: emulator: em_sysexit should update ctxt->mode Greg Kroah-Hartman
` (15 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Jim Mattson, Paolo Bonzini
From: Jim Mattson <jmattson@google.com>
commit 7030d8530e533844e2f4b0e7476498afcd324634 upstream.
KVM_GET_SUPPORTED_CPUID should only enumerate features that KVM
actually supports. The following ranges of CPUID.80000008H are reserved
and should be masked off:
ECX[31:18]
ECX[11:8]
In addition, the PerfTscSize field at ECX[17:16] should also be zero
because KVM does not set the PERFTSC bit at CPUID.80000001H.ECX[27].
Fixes: 24c82e576b78 ("KVM: Sanitize cpuid")
Signed-off-by: Jim Mattson <jmattson@google.com>
Message-Id: <20220929225203.2234702-3-jmattson@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/cpuid.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -759,6 +759,7 @@ static inline int __do_cpuid_func(struct
g_phys_as = phys_as;
entry->eax = g_phys_as | (virt_as << 8);
+ entry->ecx &= ~(GENMASK(31, 16) | GENMASK(11, 8));
entry->edx = 0;
entry->ebx &= kvm_cpuid_8000_0008_ebx_x86_features;
cpuid_mask(&entry->ebx, CPUID_8000_0008_EBX);
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 66/74] KVM: x86: emulator: em_sysexit should update ctxt->mode
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (64 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 65/74] KVM: x86: Mask off reserved bits in CPUID.80000008H Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 67/74] KVM: x86: emulator: introduce emulator_recalc_and_set_mode Greg Kroah-Hartman
` (14 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Maxim Levitsky, Paolo Bonzini
From: Maxim Levitsky <mlevitsk@redhat.com>
commit 5015bb89b58225f97df6ac44383e7e8c8662c8c9 upstream.
SYSEXIT is one of the instructions that can change the
processor mode, thus ctxt->mode should be updated after it.
Note that this is likely a benign bug, because the only problematic
mode change is from 32 bit to 64 bit which can lead to truncation of RIP,
and it is not possible to do with sysexit,
since sysexit running in 32 bit mode will be limited to 32 bit version.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20221025124741.228045-11-mlevitsk@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/emulate.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2953,6 +2953,7 @@ static int em_sysexit(struct x86_emulate
ops->set_segment(ctxt, ss_sel, &ss, 0, VCPU_SREG_SS);
ctxt->_eip = rdx;
+ ctxt->mode = usermode;
*reg_write(ctxt, VCPU_REGS_RSP) = rcx;
return X86EMUL_CONTINUE;
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 67/74] KVM: x86: emulator: introduce emulator_recalc_and_set_mode
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (65 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 66/74] KVM: x86: emulator: em_sysexit should update ctxt->mode Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 68/74] KVM: x86: emulator: update the emulation mode after CR0 write Greg Kroah-Hartman
` (13 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Maxim Levitsky, Paolo Bonzini
From: Maxim Levitsky <mlevitsk@redhat.com>
commit d087e0f79fa0dd336a9a6b2f79ec23120f5eff73 upstream.
Some instructions update the cpu execution mode, which needs to update the
emulation mode.
Extract this code, and make assign_eip_far use it.
assign_eip_far now reads CS, instead of getting it via a parameter,
which is ok, because callers always assign CS to the same value
before calling this function.
No functional change is intended.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20221025124741.228045-12-mlevitsk@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/emulate.c | 85 ++++++++++++++++++++++++++++++++-----------------
1 file changed, 57 insertions(+), 28 deletions(-)
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -776,8 +776,7 @@ static int linearize(struct x86_emulate_
ctxt->mode, linear);
}
-static inline int assign_eip(struct x86_emulate_ctxt *ctxt, ulong dst,
- enum x86emul_mode mode)
+static inline int assign_eip(struct x86_emulate_ctxt *ctxt, ulong dst)
{
ulong linear;
int rc;
@@ -787,41 +786,71 @@ static inline int assign_eip(struct x86_
if (ctxt->op_bytes != sizeof(unsigned long))
addr.ea = dst & ((1UL << (ctxt->op_bytes << 3)) - 1);
- rc = __linearize(ctxt, addr, &max_size, 1, false, true, mode, &linear);
+ rc = __linearize(ctxt, addr, &max_size, 1, false, true, ctxt->mode, &linear);
if (rc == X86EMUL_CONTINUE)
ctxt->_eip = addr.ea;
return rc;
}
+static inline int emulator_recalc_and_set_mode(struct x86_emulate_ctxt *ctxt)
+{
+ u64 efer;
+ struct desc_struct cs;
+ u16 selector;
+ u32 base3;
+
+ ctxt->ops->get_msr(ctxt, MSR_EFER, &efer);
+
+ if (!(ctxt->ops->get_cr(ctxt, 0) & X86_CR0_PE)) {
+ /* Real mode. cpu must not have long mode active */
+ if (efer & EFER_LMA)
+ return X86EMUL_UNHANDLEABLE;
+ ctxt->mode = X86EMUL_MODE_REAL;
+ return X86EMUL_CONTINUE;
+ }
+
+ if (ctxt->eflags & X86_EFLAGS_VM) {
+ /* Protected/VM86 mode. cpu must not have long mode active */
+ if (efer & EFER_LMA)
+ return X86EMUL_UNHANDLEABLE;
+ ctxt->mode = X86EMUL_MODE_VM86;
+ return X86EMUL_CONTINUE;
+ }
+
+ if (!ctxt->ops->get_segment(ctxt, &selector, &cs, &base3, VCPU_SREG_CS))
+ return X86EMUL_UNHANDLEABLE;
+
+ if (efer & EFER_LMA) {
+ if (cs.l) {
+ /* Proper long mode */
+ ctxt->mode = X86EMUL_MODE_PROT64;
+ } else if (cs.d) {
+ /* 32 bit compatibility mode*/
+ ctxt->mode = X86EMUL_MODE_PROT32;
+ } else {
+ ctxt->mode = X86EMUL_MODE_PROT16;
+ }
+ } else {
+ /* Legacy 32 bit / 16 bit mode */
+ ctxt->mode = cs.d ? X86EMUL_MODE_PROT32 : X86EMUL_MODE_PROT16;
+ }
+
+ return X86EMUL_CONTINUE;
+}
+
static inline int assign_eip_near(struct x86_emulate_ctxt *ctxt, ulong dst)
{
- return assign_eip(ctxt, dst, ctxt->mode);
+ return assign_eip(ctxt, dst);
}
-static int assign_eip_far(struct x86_emulate_ctxt *ctxt, ulong dst,
- const struct desc_struct *cs_desc)
+static int assign_eip_far(struct x86_emulate_ctxt *ctxt, ulong dst)
{
- enum x86emul_mode mode = ctxt->mode;
- int rc;
+ int rc = emulator_recalc_and_set_mode(ctxt);
-#ifdef CONFIG_X86_64
- if (ctxt->mode >= X86EMUL_MODE_PROT16) {
- if (cs_desc->l) {
- u64 efer = 0;
+ if (rc != X86EMUL_CONTINUE)
+ return rc;
- ctxt->ops->get_msr(ctxt, MSR_EFER, &efer);
- if (efer & EFER_LMA)
- mode = X86EMUL_MODE_PROT64;
- } else
- mode = X86EMUL_MODE_PROT32; /* temporary value */
- }
-#endif
- if (mode == X86EMUL_MODE_PROT16 || mode == X86EMUL_MODE_PROT32)
- mode = cs_desc->d ? X86EMUL_MODE_PROT32 : X86EMUL_MODE_PROT16;
- rc = assign_eip(ctxt, dst, mode);
- if (rc == X86EMUL_CONTINUE)
- ctxt->mode = mode;
- return rc;
+ return assign_eip(ctxt, dst);
}
static inline int jmp_rel(struct x86_emulate_ctxt *ctxt, int rel)
@@ -2237,7 +2266,7 @@ static int em_jmp_far(struct x86_emulate
if (rc != X86EMUL_CONTINUE)
return rc;
- rc = assign_eip_far(ctxt, ctxt->src.val, &new_desc);
+ rc = assign_eip_far(ctxt, ctxt->src.val);
/* Error handling is not implemented. */
if (rc != X86EMUL_CONTINUE)
return X86EMUL_UNHANDLEABLE;
@@ -2318,7 +2347,7 @@ static int em_ret_far(struct x86_emulate
&new_desc);
if (rc != X86EMUL_CONTINUE)
return rc;
- rc = assign_eip_far(ctxt, eip, &new_desc);
+ rc = assign_eip_far(ctxt, eip);
/* Error handling is not implemented. */
if (rc != X86EMUL_CONTINUE)
return X86EMUL_UNHANDLEABLE;
@@ -3550,7 +3579,7 @@ static int em_call_far(struct x86_emulat
if (rc != X86EMUL_CONTINUE)
return rc;
- rc = assign_eip_far(ctxt, ctxt->src.val, &new_desc);
+ rc = assign_eip_far(ctxt, ctxt->src.val);
if (rc != X86EMUL_CONTINUE)
goto fail;
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 68/74] KVM: x86: emulator: update the emulation mode after CR0 write
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (66 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 67/74] KVM: x86: emulator: introduce emulator_recalc_and_set_mode Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 69/74] mtd: rawnand: gpmi: Set WAIT_FOR_READY timeout based on program/erase times Greg Kroah-Hartman
` (12 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Maxim Levitsky, Paolo Bonzini
From: Maxim Levitsky <mlevitsk@redhat.com>
commit ad8f9e69942c7db90758d9d774157e53bce94840 upstream.
Update the emulation mode when handling writes to CR0, because
toggling CR0.PE switches between Real and Protected Mode, and toggling
CR0.PG when EFER.LME=1 switches between Long and Protected Mode.
This is likely a benign bug because there is no writeback of state,
other than the RIP increment, and when toggling CR0.PE, the CPU has
to execute code from a very low memory address.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20221025124741.228045-14-mlevitsk@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/emulate.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -3726,11 +3726,25 @@ static int em_movbe(struct x86_emulate_c
static int em_cr_write(struct x86_emulate_ctxt *ctxt)
{
- if (ctxt->ops->set_cr(ctxt, ctxt->modrm_reg, ctxt->src.val))
+ int cr_num = ctxt->modrm_reg;
+ int r;
+
+ if (ctxt->ops->set_cr(ctxt, cr_num, ctxt->src.val))
return emulate_gp(ctxt, 0);
/* Disable writeback. */
ctxt->dst.type = OP_NONE;
+
+ if (cr_num == 0) {
+ /*
+ * CR0 write might have updated CR0.PE and/or CR0.PG
+ * which can affect the cpu's execution mode.
+ */
+ r = emulator_recalc_and_set_mode(ctxt);
+ if (r != X86EMUL_CONTINUE)
+ return r;
+ }
+
return X86EMUL_CONTINUE;
}
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 69/74] mtd: rawnand: gpmi: Set WAIT_FOR_READY timeout based on program/erase times
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (67 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 68/74] KVM: x86: emulator: update the emulation mode after CR0 write Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 70/74] drm/rockchip: dsi: Force synchronous probe Greg Kroah-Hartman
` (11 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Sascha Hauer, Han Xu,
Tomasz Moń,
Richard Weinberger, Tim Harvey
From: Sascha Hauer <s.hauer@pengutronix.de>
commit 0fddf9ad06fd9f439f137139861556671673e31c upstream.
06781a5026350 Fixes the calculation of the DEVICE_BUSY_TIMEOUT register
value from busy_timeout_cycles. busy_timeout_cycles is calculated wrong
though: It is calculated based on the maximum page read time, but the
timeout is also used for page write and block erase operations which
require orders of magnitude bigger timeouts.
Fix this by calculating busy_timeout_cycles from the maximum of
tBERS_max and tPROG_max.
This is for now the easiest and most obvious way to fix the driver.
There's room for improvements though: The NAND_OP_WAITRDY_INSTR tells us
the desired timeout for the current operation, so we could program the
timeout dynamically for each operation instead of setting a fixed
timeout. Also we could wire up the interrupt handler to actually detect
and forward timeouts occurred when waiting for the chip being ready.
As a sidenote I verified that the change in 06781a5026350 is really
correct. I wired up the interrupt handler in my tree and measured the
time between starting the operation and the timeout interrupt handler
coming in. The time increases 41us with each step in the timeout
register which corresponds to 4096 clock cycles with the 99MHz clock
that I have.
Fixes: 06781a5026350 ("mtd: rawnand: gpmi: Fix setting busy timeout setting")
Fixes: b1206122069aa ("mtd: rawniand: gpmi: use core timings instead of an empirical derivation")
Cc: stable@vger.kernel.org
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Han Xu <han.xu@nxp.com>
Tested-by: Tomasz Moń <tomasz.mon@camlingroup.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
@@ -652,8 +652,9 @@ static void gpmi_nfc_compute_timings(str
unsigned int tRP_ps;
bool use_half_period;
int sample_delay_ps, sample_delay_factor;
- u16 busy_timeout_cycles;
+ unsigned int busy_timeout_cycles;
u8 wrn_dly_sel;
+ u64 busy_timeout_ps;
if (sdr->tRC_min >= 30000) {
/* ONFI non-EDO modes [0-3] */
@@ -677,7 +678,8 @@ static void gpmi_nfc_compute_timings(str
addr_setup_cycles = TO_CYCLES(sdr->tALS_min, period_ps);
data_setup_cycles = TO_CYCLES(sdr->tDS_min, period_ps);
data_hold_cycles = TO_CYCLES(sdr->tDH_min, period_ps);
- busy_timeout_cycles = TO_CYCLES(sdr->tWB_max + sdr->tR_max, period_ps);
+ busy_timeout_ps = max(sdr->tBERS_max, sdr->tPROG_max);
+ busy_timeout_cycles = TO_CYCLES(busy_timeout_ps, period_ps);
hw->timing0 = BF_GPMI_TIMING0_ADDRESS_SETUP(addr_setup_cycles) |
BF_GPMI_TIMING0_DATA_HOLD(data_hold_cycles) |
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 70/74] drm/rockchip: dsi: Force synchronous probe
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (68 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 69/74] mtd: rawnand: gpmi: Set WAIT_FOR_READY timeout based on program/erase times Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 71/74] drm/i915/sdvo: Filter out invalid outputs more sensibly Greg Kroah-Hartman
` (10 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Brian Norris, Heiko Stuebner
From: Brian Norris <briannorris@chromium.org>
commit 81e592f86f7afdb76d655e7fbd7803d7b8f985d8 upstream.
We can't safely probe a dual-DSI display asynchronously
(driver_async_probe='*' or driver_async_probe='dw-mipi-dsi-rockchip'
cmdline), because dw_mipi_dsi_rockchip_find_second() pokes one DSI
device's drvdata from the other device without any locking.
Request synchronous probe, at least until this driver learns some
appropriate locking for dual-DSI initialization.
Cc: <stable@vger.kernel.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20221019170255.2.I6b985b0ca372b7e35c6d9ea970b24bcb262d4fc1@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -1123,5 +1123,11 @@ struct platform_driver dw_mipi_dsi_rockc
.of_match_table = dw_mipi_dsi_rockchip_dt_ids,
.pm = &dw_mipi_dsi_rockchip_pm_ops,
.name = "dw-mipi-dsi-rockchip",
+ /*
+ * For dual-DSI display, one DSI pokes at the other DSI's
+ * drvdata in dw_mipi_dsi_rockchip_find_second(). This is not
+ * safe for asynchronous probe.
+ */
+ .probe_type = PROBE_FORCE_SYNCHRONOUS,
},
};
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 71/74] drm/i915/sdvo: Filter out invalid outputs more sensibly
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (69 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 70/74] drm/rockchip: dsi: Force synchronous probe Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 72/74] drm/i915/sdvo: Setup DDC fully before output init Greg Kroah-Hartman
` (9 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Ville Syrjälä,
Jani Nikula, Tvrtko Ursulin
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
commit 3e206b6aa6df7eed4297577e0cf8403169b800a2 upstream.
We try to filter out the corresponding xxx1 output
if the xxx0 output is not present. But the way that is
being done is pretty awkward. Make it less so.
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit cc1e66394daaa7e9f005e2487a84e34a39f9308b)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 27 ++++++++++++++++++++++-----
1 file changed, 22 insertions(+), 5 deletions(-)
--- a/drivers/gpu/drm/i915/display/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
@@ -2869,16 +2869,33 @@ err:
return false;
}
+static u16 intel_sdvo_filter_output_flags(u16 flags)
+{
+ flags &= SDVO_OUTPUT_MASK;
+
+ /* SDVO requires XXX1 function may not exist unless it has XXX0 function.*/
+ if (!(flags & SDVO_OUTPUT_TMDS0))
+ flags &= ~SDVO_OUTPUT_TMDS1;
+
+ if (!(flags & SDVO_OUTPUT_RGB0))
+ flags &= ~SDVO_OUTPUT_RGB1;
+
+ if (!(flags & SDVO_OUTPUT_LVDS0))
+ flags &= ~SDVO_OUTPUT_LVDS1;
+
+ return flags;
+}
+
static bool
intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo, u16 flags)
{
- /* SDVO requires XXX1 function may not exist unless it has XXX0 function.*/
+ flags = intel_sdvo_filter_output_flags(flags);
if (flags & SDVO_OUTPUT_TMDS0)
if (!intel_sdvo_dvi_init(intel_sdvo, 0))
return false;
- if ((flags & SDVO_TMDS_MASK) == SDVO_TMDS_MASK)
+ if (flags & SDVO_OUTPUT_TMDS1)
if (!intel_sdvo_dvi_init(intel_sdvo, 1))
return false;
@@ -2899,7 +2916,7 @@ intel_sdvo_output_setup(struct intel_sdv
if (!intel_sdvo_analog_init(intel_sdvo, 0))
return false;
- if ((flags & SDVO_RGB_MASK) == SDVO_RGB_MASK)
+ if (flags & SDVO_OUTPUT_RGB1)
if (!intel_sdvo_analog_init(intel_sdvo, 1))
return false;
@@ -2907,11 +2924,11 @@ intel_sdvo_output_setup(struct intel_sdv
if (!intel_sdvo_lvds_init(intel_sdvo, 0))
return false;
- if ((flags & SDVO_LVDS_MASK) == SDVO_LVDS_MASK)
+ if (flags & SDVO_OUTPUT_LVDS1)
if (!intel_sdvo_lvds_init(intel_sdvo, 1))
return false;
- if ((flags & SDVO_OUTPUT_MASK) == 0) {
+ if (flags == 0) {
unsigned char bytes[2];
intel_sdvo->controlled_output = 0;
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 72/74] drm/i915/sdvo: Setup DDC fully before output init
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (70 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 71/74] drm/i915/sdvo: Filter out invalid outputs more sensibly Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 73/74] wifi: brcmfmac: Fix potential buffer overflow in brcmf_fweh_event_worker() Greg Kroah-Hartman
` (8 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Ville Syrjälä,
Jani Nikula, Tvrtko Ursulin
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
commit e79762512120f11c51317570519a1553c70805d8 upstream.
Call intel_sdvo_select_ddc_bus() before initializing any
of the outputs. And before that is functional (assuming no VBT)
we have to set up the controlled_outputs thing. Otherwise DDC
won't be functional during the output init but LVDS really
needs it for the fixed mode setup.
Note that the whole multi output support still looks very
bogus, and more work will be needed to make it correct.
But for now this should at least fix the LVDS EDID fixed mode
setup.
Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301
Fixes: aa2b88074a56 ("drm/i915/sdvo: Fix multi function encoder stuff")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 64b7b557dc8a96d9cfed6aedbf81de2df80c025d)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 31 +++++++++++-------------------
1 file changed, 12 insertions(+), 19 deletions(-)
--- a/drivers/gpu/drm/i915/display/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
@@ -2693,13 +2693,10 @@ intel_sdvo_dvi_init(struct intel_sdvo *i
if (!intel_sdvo_connector)
return false;
- if (device == 0) {
- intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS0;
+ if (device == 0)
intel_sdvo_connector->output_flag = SDVO_OUTPUT_TMDS0;
- } else if (device == 1) {
- intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS1;
+ else if (device == 1)
intel_sdvo_connector->output_flag = SDVO_OUTPUT_TMDS1;
- }
intel_connector = &intel_sdvo_connector->base;
connector = &intel_connector->base;
@@ -2753,7 +2750,6 @@ intel_sdvo_tv_init(struct intel_sdvo *in
encoder->encoder_type = DRM_MODE_ENCODER_TVDAC;
connector->connector_type = DRM_MODE_CONNECTOR_SVIDEO;
- intel_sdvo->controlled_output |= type;
intel_sdvo_connector->output_flag = type;
if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo) < 0) {
@@ -2794,13 +2790,10 @@ intel_sdvo_analog_init(struct intel_sdvo
encoder->encoder_type = DRM_MODE_ENCODER_DAC;
connector->connector_type = DRM_MODE_CONNECTOR_VGA;
- if (device == 0) {
- intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB0;
+ if (device == 0)
intel_sdvo_connector->output_flag = SDVO_OUTPUT_RGB0;
- } else if (device == 1) {
- intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB1;
+ else if (device == 1)
intel_sdvo_connector->output_flag = SDVO_OUTPUT_RGB1;
- }
if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo) < 0) {
kfree(intel_sdvo_connector);
@@ -2830,13 +2823,10 @@ intel_sdvo_lvds_init(struct intel_sdvo *
encoder->encoder_type = DRM_MODE_ENCODER_LVDS;
connector->connector_type = DRM_MODE_CONNECTOR_LVDS;
- if (device == 0) {
- intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS0;
+ if (device == 0)
intel_sdvo_connector->output_flag = SDVO_OUTPUT_LVDS0;
- } else if (device == 1) {
- intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS1;
+ else if (device == 1)
intel_sdvo_connector->output_flag = SDVO_OUTPUT_LVDS1;
- }
if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo) < 0) {
kfree(intel_sdvo_connector);
@@ -2889,8 +2879,14 @@ static u16 intel_sdvo_filter_output_flag
static bool
intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo, u16 flags)
{
+ struct drm_i915_private *i915 = to_i915(intel_sdvo->base.base.dev);
+
flags = intel_sdvo_filter_output_flags(flags);
+ intel_sdvo->controlled_output = flags;
+
+ intel_sdvo_select_ddc_bus(i915, intel_sdvo);
+
if (flags & SDVO_OUTPUT_TMDS0)
if (!intel_sdvo_dvi_init(intel_sdvo, 0))
return false;
@@ -2931,7 +2927,6 @@ intel_sdvo_output_setup(struct intel_sdv
if (flags == 0) {
unsigned char bytes[2];
- intel_sdvo->controlled_output = 0;
memcpy(bytes, &intel_sdvo->caps.output_flags, 2);
DRM_DEBUG_KMS("%s: Unknown SDVO output type (0x%02x%02x)\n",
SDVO_NAME(intel_sdvo),
@@ -3338,8 +3333,6 @@ bool intel_sdvo_init(struct drm_i915_pri
*/
intel_sdvo->base.cloneable = 0;
- intel_sdvo_select_ddc_bus(dev_priv, intel_sdvo);
-
/* Set the input timing to the screen. Assume always input 0. */
if (!intel_sdvo_set_target_input(intel_sdvo))
goto err_output;
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 73/74] wifi: brcmfmac: Fix potential buffer overflow in brcmf_fweh_event_worker()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (71 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 72/74] drm/i915/sdvo: Setup DDC fully before output init Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 13:39 ` [PATCH 5.4 74/74] ipc: remove memcg accounting for sops objects in do_semtimedop() Greg Kroah-Hartman
` (7 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Dokyung Song, Jisoo Jang,
Minsuk Kang, Arend van Spriel, Dokyung Song, Kalle Valo
From: Dokyung Song <dokyung.song@gmail.com>
commit 6788ba8aed4e28e90f72d68a9d794e34eac17295 upstream.
This patch fixes an intra-object buffer overflow in brcmfmac that occurs
when the device provides a 'bsscfgidx' equal to or greater than the
buffer size. The patch adds a check that leads to a safe failure if that
is the case.
This fixes CVE-2022-3628.
UBSAN: array-index-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
index 52 is out of range for type 'brcmf_if *[16]'
CPU: 0 PID: 1898 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
Workqueue: events brcmf_fweh_event_worker
Call Trace:
dump_stack_lvl+0x57/0x7d
ubsan_epilogue+0x5/0x40
__ubsan_handle_out_of_bounds+0x69/0x80
? memcpy+0x39/0x60
brcmf_fweh_event_worker+0xae1/0xc00
? brcmf_fweh_call_event_handler.isra.0+0x100/0x100
? rcu_read_lock_sched_held+0xa1/0xd0
? rcu_read_lock_bh_held+0xb0/0xb0
? lockdep_hardirqs_on_prepare+0x273/0x3e0
process_one_work+0x873/0x13e0
? lock_release+0x640/0x640
? pwq_dec_nr_in_flight+0x320/0x320
? rwlock_bug.part.0+0x90/0x90
worker_thread+0x8b/0xd10
? __kthread_parkme+0xd9/0x1d0
? process_one_work+0x13e0/0x13e0
kthread+0x379/0x450
? _raw_spin_unlock_irq+0x24/0x30
? set_kthread_struct+0x100/0x100
ret_from_fork+0x1f/0x30
================================================================================
general protection fault, probably for non-canonical address 0xe5601c0020023fff: 0000 [#1] SMP KASAN
KASAN: maybe wild-memory-access in range [0x2b0100010011fff8-0x2b0100010011ffff]
CPU: 0 PID: 1898 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
Workqueue: events brcmf_fweh_event_worker
RIP: 0010:brcmf_fweh_call_event_handler.isra.0+0x42/0x100
Code: 89 f5 53 48 89 fb 48 83 ec 08 e8 79 0b 38 fe 48 85 ed 74 7e e8 6f 0b 38 fe 48 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 8b 00 00 00 4c 8b 7d 00 44 89 e0 48 ba 00 00 00
RSP: 0018:ffffc9000259fbd8 EFLAGS: 00010207
RAX: dffffc0000000000 RBX: ffff888115d8cd50 RCX: 0000000000000000
RDX: 0560200020023fff RSI: ffffffff8304bc91 RDI: ffff888115d8cd50
RBP: 2b0100010011ffff R08: ffff888112340050 R09: ffffed1023549809
R10: ffff88811aa4c047 R11: ffffed1023549808 R12: 0000000000000045
R13: ffffc9000259fca0 R14: ffff888112340050 R15: ffff888112340000
FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000004053ccc0 CR3: 0000000112740000 CR4: 0000000000750ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
brcmf_fweh_event_worker+0x117/0xc00
? brcmf_fweh_call_event_handler.isra.0+0x100/0x100
? rcu_read_lock_sched_held+0xa1/0xd0
? rcu_read_lock_bh_held+0xb0/0xb0
? lockdep_hardirqs_on_prepare+0x273/0x3e0
process_one_work+0x873/0x13e0
? lock_release+0x640/0x640
? pwq_dec_nr_in_flight+0x320/0x320
? rwlock_bug.part.0+0x90/0x90
worker_thread+0x8b/0xd10
? __kthread_parkme+0xd9/0x1d0
? process_one_work+0x13e0/0x13e0
kthread+0x379/0x450
? _raw_spin_unlock_irq+0x24/0x30
? set_kthread_struct+0x100/0x100
ret_from_fork+0x1f/0x30
Modules linked in: 88XXau(O) 88x2bu(O)
---[ end trace 41d302138f3ff55a ]---
RIP: 0010:brcmf_fweh_call_event_handler.isra.0+0x42/0x100
Code: 89 f5 53 48 89 fb 48 83 ec 08 e8 79 0b 38 fe 48 85 ed 74 7e e8 6f 0b 38 fe 48 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 8b 00 00 00 4c 8b 7d 00 44 89 e0 48 ba 00 00 00
RSP: 0018:ffffc9000259fbd8 EFLAGS: 00010207
RAX: dffffc0000000000 RBX: ffff888115d8cd50 RCX: 0000000000000000
RDX: 0560200020023fff RSI: ffffffff8304bc91 RDI: ffff888115d8cd50
RBP: 2b0100010011ffff R08: ffff888112340050 R09: ffffed1023549809
R10: ffff88811aa4c047 R11: ffffed1023549808 R12: 0000000000000045
R13: ffffc9000259fca0 R14: ffff888112340050 R15: ffff888112340000
FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000004053ccc0 CR3: 0000000112740000 CR4: 0000000000750ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Kernel panic - not syncing: Fatal exception
Reported-by: Dokyung Song <dokyungs@yonsei.ac.kr>
Reported-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr>
Reported-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
Reviewed-by: Arend van Spriel <aspriel@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Dokyung Song <dokyung.song@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221021061359.GA550858@laguna
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
@@ -228,6 +228,10 @@ static void brcmf_fweh_event_worker(stru
brcmf_fweh_event_name(event->code), event->code,
event->emsg.ifidx, event->emsg.bsscfgidx,
event->emsg.addr);
+ if (event->emsg.bsscfgidx >= BRCMF_MAX_IFS) {
+ bphy_err(drvr, "invalid bsscfg index: %u\n", event->emsg.bsscfgidx);
+ goto event_free;
+ }
/* convert event message */
emsg_be = &event->emsg;
^ permalink raw reply [flat|nested] 82+ messages in thread* [PATCH 5.4 74/74] ipc: remove memcg accounting for sops objects in do_semtimedop()
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (72 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 73/74] wifi: brcmfmac: Fix potential buffer overflow in brcmf_fweh_event_worker() Greg Kroah-Hartman
@ 2022-11-08 13:39 ` Greg Kroah-Hartman
2022-11-08 19:02 ` [PATCH 5.4 00/74] 5.4.224-rc1 review Florian Fainelli
` (6 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Greg Kroah-Hartman @ 2022-11-08 13:39 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Vasily Averin, Michal Hocko,
Michal Koutný,
Shakeel Butt, Linus Torvalds
From: Vasily Averin <vvs@virtuozzo.com>
commit 6a4746ba06191e23d30230738e94334b26590a8a upstream.
Linus proposes to revert an accounting for sops objects in
do_semtimedop() because it's really just a temporary buffer
for a single semtimedop() system call.
This object can consume up to 2 pages, syscall is sleeping
one, size and duration can be controlled by user, and this
allocation can be repeated by many thread at the same time.
However Shakeel Butt pointed that there are much more popular
objects with the same life time and similar memory
consumption, the accounting of which was decided to be
rejected for performance reasons.
Considering at least 2 pages for task_struct and 2 pages for
the kernel stack, a back of the envelope calculation gives a
footprint amplification of <1.5 so this temporal buffer can be
safely ignored.
The factor would IMO be interesting if it was >> 2 (from the
PoV of excessive (ab)use, fine-grained accounting seems to be
currently unfeasible due to performance impact).
Link: https://lore.kernel.org/lkml/90e254df-0dfe-f080-011e-b7c53ee7fd20@virtuozzo.com/
Fixes: 18319498fdd4 ("memcg: enable accounting of ipc resources")
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Michal Koutný <mkoutny@suse.com>
Acked-by: Shakeel Butt <shakeelb@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
ipc/sem.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1984,8 +1984,7 @@ static long do_semtimedop(int semid, str
if (nsops > ns->sc_semopm)
return -E2BIG;
if (nsops > SEMOPM_FAST) {
- sops = kvmalloc_array(nsops, sizeof(*sops),
- GFP_KERNEL_ACCOUNT);
+ sops = kvmalloc_array(nsops, sizeof(*sops), GFP_KERNEL);
if (sops == NULL)
return -ENOMEM;
}
^ permalink raw reply [flat|nested] 82+ messages in thread* Re: [PATCH 5.4 00/74] 5.4.224-rc1 review
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (73 preceding siblings ...)
2022-11-08 13:39 ` [PATCH 5.4 74/74] ipc: remove memcg accounting for sops objects in do_semtimedop() Greg Kroah-Hartman
@ 2022-11-08 19:02 ` Florian Fainelli
2022-11-09 2:57 ` Guenter Roeck
` (5 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Florian Fainelli @ 2022-11-08 19:02 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, sudipm.mukherjee, srw
On 11/8/2022 5:38 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.224 release.
> There are 74 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 Thu, 10 Nov 2022 13:33:17 +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/v5.x/stable-review/patch-5.4.224-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-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on
BMIPS_GENERIC:
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply [flat|nested] 82+ messages in thread* Re: [PATCH 5.4 00/74] 5.4.224-rc1 review
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (74 preceding siblings ...)
2022-11-08 19:02 ` [PATCH 5.4 00/74] 5.4.224-rc1 review Florian Fainelli
@ 2022-11-09 2:57 ` Guenter Roeck
2022-11-09 10:47 ` Jon Hunter
` (4 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Guenter Roeck @ 2022-11-09 2:57 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw
On Tue, Nov 08, 2022 at 02:38:28PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.224 release.
> There are 74 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 Thu, 10 Nov 2022 13:33:17 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 161 pass: 161 fail: 0
Qemu test results:
total: 447 pass: 447 fail: 0
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
^ permalink raw reply [flat|nested] 82+ messages in thread* Re: [PATCH 5.4 00/74] 5.4.224-rc1 review
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (75 preceding siblings ...)
2022-11-09 2:57 ` Guenter Roeck
@ 2022-11-09 10:47 ` Jon Hunter
2022-11-09 13:31 ` Naresh Kamboju
` (3 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Jon Hunter @ 2022-11-09 10:47 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, linux-tegra
On Tue, 08 Nov 2022 14:38:28 +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.224 release.
> There are 74 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 Thu, 10 Nov 2022 13:33:17 +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/v5.x/stable-review/patch-5.4.224-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-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v5.4:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
59 tests: 59 pass, 0 fail
Linux version: 5.4.224-rc1-gdc8d80bb822a
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 82+ messages in thread* Re: [PATCH 5.4 00/74] 5.4.224-rc1 review
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (76 preceding siblings ...)
2022-11-09 10:47 ` Jon Hunter
@ 2022-11-09 13:31 ` Naresh Kamboju
2022-11-10 1:55 ` Shuah Khan
` (2 subsequent siblings)
80 siblings, 0 replies; 82+ messages in thread
From: Naresh Kamboju @ 2022-11-09 13:31 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw
On Tue, 8 Nov 2022 at 19:18, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.4.224 release.
> There are 74 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 Thu, 10 Nov 2022 13:33:17 +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/v5.x/stable-review/patch-5.4.224-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-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro's test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
## Build
* kernel: 5.4.224-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.4.y
* git commit: dc8d80bb822aa0a393ccaa810d63be127d1bd864
* git describe: v5.4.223-75-gdc8d80bb822a
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.223-75-gdc8d80bb822a
## Test Regressions (compared to v5.4.222)
## Metric Regressions (compared to v5.4.222)
## Test Fixes (compared to v5.4.222)
## Metric Fixes (compared to v5.4.222)
## Test result summary
total: 130360, pass: 110431, fail: 2196, skip: 17226, xfail: 507
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 334 total, 334 passed, 0 failed
* arm64: 64 total, 59 passed, 5 failed
* i386: 31 total, 29 passed, 2 failed
* mips: 56 total, 56 passed, 0 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 63 total, 63 passed, 0 failed
* riscv: 27 total, 26 passed, 1 failed
* s390: 15 total, 15 passed, 0 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x86_64: 57 total, 55 passed, 2 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* packetdrill
* perf
* perf/Zstd-perf.data-compression
* rcutorture
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 82+ messages in thread* Re: [PATCH 5.4 00/74] 5.4.224-rc1 review
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (77 preceding siblings ...)
2022-11-09 13:31 ` Naresh Kamboju
@ 2022-11-10 1:55 ` Shuah Khan
2022-11-10 10:49 ` Sudip Mukherjee
2022-11-11 1:19 ` zhouzhixiu
80 siblings, 0 replies; 82+ messages in thread
From: Shuah Khan @ 2022-11-10 1:55 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
Shuah Khan
On 11/8/22 06:38, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.224 release.
> There are 74 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 Thu, 10 Nov 2022 13:33:17 +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/v5.x/stable-review/patch-5.4.224-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-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 82+ messages in thread* Re: [PATCH 5.4 00/74] 5.4.224-rc1 review
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (78 preceding siblings ...)
2022-11-10 1:55 ` Shuah Khan
@ 2022-11-10 10:49 ` Sudip Mukherjee
2022-11-11 1:19 ` zhouzhixiu
80 siblings, 0 replies; 82+ messages in thread
From: Sudip Mukherjee @ 2022-11-10 10:49 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli, srw
Hi Greg,
On Tue, Nov 08, 2022 at 02:38:28PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.224 release.
> There are 74 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 Thu, 10 Nov 2022 13:33:17 +0000.
> Anything received after that time might be too late.
Build test (gcc version 11.3.1 20221016):
mips: 65 configs -> no failure
arm: 106 configs -> no failure
arm64: 2 configs -> no failure
x86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure
Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression. [1]
[1]. https://openqa.qa.codethink.co.uk/tests/2132
Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
--
Regards
Sudip
^ permalink raw reply [flat|nested] 82+ messages in thread* Re: [PATCH 5.4 00/74] 5.4.224-rc1 review
2022-11-08 13:38 [PATCH 5.4 00/74] 5.4.224-rc1 review Greg Kroah-Hartman
` (79 preceding siblings ...)
2022-11-10 10:49 ` Sudip Mukherjee
@ 2022-11-11 1:19 ` zhouzhixiu
80 siblings, 0 replies; 82+ messages in thread
From: zhouzhixiu @ 2022-11-11 1:19 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw
On 2022/11/8 21:38, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.224 release.
> There are 74 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 Thu, 10 Nov 2022 13:33:17 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be fD:\00_工作目录\00_工作笔记\#常用网站记录.mdound in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.224-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-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
Tested on arm64 and x86 for 5.4.224-rc1,
Kernel
repo:https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-5.4.y
Version: 5.4.224-rc1
Commit: dc8d80bb822aa0a393ccaa810d63be127d1bd864
Compiler: gcc version 7.3.0 (GCC)
arm64:
--------------------------------------------------------------------
Testcase Result Summary:
total: 9017
passed: 9017
failed: 0
timeout: 0
--------------------------------------------------------------------
x86:
--------------------------------------------------------------------
Testcase Result Summary:
total: 9017
passed: 9017
failed: 0
timeout: 0
--------------------------------------------------------------------
Tested-by: Hulk Robot <hulkrobot@huawei.com>
^ permalink raw reply [flat|nested] 82+ messages in thread