The current code registers the node as available in the node array
before initializing the accessor list.  This makes it so that
anything which might access the accessor list as a result of
allocations will cause an undefined memory access.

In one example, an extension to access hmat data during interleave
caused this undefined access as a result of a bulk allocation
that occurs during node initialization but before the accessor
list is initialized.

Initialize the accessor list before making the node generally
available to the global system.

Signed-off-by: Gregory Price <gregory.price@memverge.com>
---
 drivers/base/node.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/base/node.c b/drivers/base/node.c
index 493d533f8375..4d588f4658c8 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -868,11 +868,15 @@ int __register_one_node(int nid)
 {
 	int error;
 	int cpu;
+	struct node *node;
 
-	node_devices[nid] = kzalloc(sizeof(struct node), GFP_KERNEL);
-	if (!node_devices[nid])
+	node = kzalloc(sizeof(struct node), GFP_KERNEL);
+	if (!node)
 		return -ENOMEM;
 
+	INIT_LIST_HEAD(&node->access_list);
+	node_devices[nid] = node;
+
 	error = register_node(node_devices[nid], nid);
 
 	/* link cpu under this node */
@@ -881,7 +885,6 @@ int __register_one_node(int nid)
 			register_cpu_under_node(cpu, nid);
 	}
 
-	INIT_LIST_HEAD(&node_devices[nid]->access_list);
 	node_init_caches(nid);
 
 	return error;
-- 
2.39.1

On Mon, Oct 30, 2023 at 12:42:39AM -0400, Gregory Price wrote:
> The current code registers the node as available in the node array
> before initializing the accessor list.  This makes it so that
> anything which might access the accessor list as a result of
> allocations will cause an undefined memory access.
> 
> In one example, an extension to access hmat data during interleave
> caused this undefined access as a result of a bulk allocation
> that occurs during node initialization but before the accessor
> list is initialized.

Is this an in-kernel driver that causes this problem?

> 
> Initialize the accessor list before making the node generally
> available to the global system.
> 
> Signed-off-by: Gregory Price <gregory.price@memverge.com>

What commit id does this fix?

thanks,

greg k-h

On Tue, Oct 31, 2023 at 07:03:17AM +0100, Greg KH wrote:
> On Mon, Oct 30, 2023 at 12:42:39AM -0400, Gregory Price wrote:
> > The current code registers the node as available in the node array
> > before initializing the accessor list.  This makes it so that
> > anything which might access the accessor list as a result of
> > allocations will cause an undefined memory access.
> > 
> > In one example, an extension to access hmat data during interleave
> > caused this undefined access as a result of a bulk allocation
> > that occurs during node initialization but before the accessor
> > list is initialized.
> 
> Is this an in-kernel driver that causes this problem?
> 

I discovered this why testing an RFC:
https://lore.kernel.org/linux-mm/ZUCCoCRS3cohf9OE@memverge.com/T/#t

However I noticed that there are two exposed interfaces which may
allow a caller to hit the unitialized accessor list.  I haven't
explicitly demonstrated this, though.

1) register_memory_node_under_compute_node
2) node_set_perf_attrs

Since `register_node` calls into device_register and inevitably hits
allocators, it seems like fully initializing the node struct before
going off into the aether was appropriate.

> > 
> > Initialize the accessor list before making the node generally
> > available to the global system.
> > 
> > Signed-off-by: Gregory Price <gregory.price@memverge.com>
> 
> What commit id does this fix?
>

Sorry:
Fixes: 08d9dbe72b1f ("node: Link memory nodes to their compute nodes")

> thanks,
> 
> greg k-h