• The number of nodes in the tree is in the range [1, 500]
• 0 <= Node.val <= 500, and all values are unique
• target is guaranteed to be a node of the tree
• 0 <= k <= 1000, so k may exceed the tree's reach

If the question were "which nodes are k steps below the target", it would be a short recursion: descend k levels and collect whatever you land on. The difficulty is that distance here is measured along edges travelled in either direction, so the answer can include the target's parent, its grandparent, and whole subtrees hanging off ancestors — regions no downward walk from the target ever reaches.

The obstacle is structural rather than conceptual. Each node holds pointers to its children and nothing else, so from the target we can go down but never up. That asymmetry is a fact about our representation, not about the problem: the edge between a parent and a child is perfectly symmetric, and the question treats it that way. We are simply missing half of every edge.

So add what is missing. Walk the tree once and record, for every node, who its parent is — a map from node to parent, with the root mapping to nothing. Now every node has up to three neighbours: left child, right child, and parent.

At that point the tree stops mattering. What we have is an undirected graph — nodes joined by two-way edges — and "which nodes are exactly k edges from this one" is the standard graph question of expanding outward in rings: everything one edge away, then everything two edges away, and so on. Breadth-first search from the target does exactly that, and the ring reached on step k is the answer.

There is one new obligation compared with tree traversals. In a tree, moving away from the root can never revisit a node, so no bookkeeping is needed. With two-way edges you can walk straight back where you came from — target to parent, parent back to target — looping forever and reporting nodes at the wrong distance. So keep a visited set and admit each node once, on its first arrival. Because breadth-first search reaches a node along its shortest path first, that first arrival is at the node's true distance, which makes blocking later arrivals both safe and necessary.

parent = {}
def map_parents(node, par):
    if node is None: return
    parent[node] = par
    map_parents(node.left, node)
    map_parents(node.right, node)
map_parents(root, None)

queue, seen, dist = deque([target]), {target}, 0
while queue:
    if dist == k:
        return [n.val for n in queue]      # this entire ring is exactly k away
    for _ in range(len(queue)):            # frozen ring size — expand one ring at a time
        node = queue.popleft()
        for nxt in (node.left, node.right, parent[node]):
            if nxt and nxt not in seen:
                seen.add(nxt)
                queue.append(nxt)
    dist += 1
return []

The frozen len(queue) is the same level-boundary device from Binary Tree Level Order Traversal, doing the same job — except that here a "level" is a ring of equal distance rather than a row of the tree.

Node 1 is the payoff: it was reached by going up from 5 to 3 and then down again, a route the original pointers made impossible. And node 5 never reappeared, because the visited set stopped 3 from walking back into it.

Building the parent map visits every node once, and the search admits every node at most once, so the total is O(N) time with O(N) space for the map, the visited set and the queue.

The move worth remembering is the reframing itself: when a tree problem needs to travel upward, stop treating it as a tree and turn it into a graph. Add the parent edges, then apply whichever graph algorithm the question actually wants — breadth-first search for distances, depth-first for reachability. Spotting this early converts a family of awkward-looking tree problems into standard graph exercises, and the next problem, Amount of Time for Binary Tree to Be Infected, is the same construction with a different question asked of the same rings.