Memory leak when freeing linked list

I have been learning C, and am having a had time getting used to memory management in C. I wrote this program after learning about linked lists:

#include <stdio.h>
#include <stdlib.h>

struct node {
    int x;
    struct node *next;
};

void free_node(struct node *n) {
    struct node *p, *next;
    for (p = n; p != NULL; p = next) {
        next = p->next;
        free(p);
    }
}

int main(int argc, char const *argv[]) {

    int i;
    struct node *n, *p, *root = malloc(sizeof(struct node));
    root->x = 0;
    n = root;

    for (i = 1; i <= 5; ++i) {
        struct node *next = malloc(sizeof(struct node));
        next->x = i;
        n->next = next;
        n = n->next;
    }
    n->next = NULL;

    // print values
    for (p = root; p != NULL; p = p->next) {
        printf("%i\n", p->x);
    }

    free_node(n);

    return 0;
}

Most of the tutorials I've read did a bad job of explaining memory management in C, if even mentioning it at all. I would thing this code would free all the malloc'ed memory but when I run this: valgrind --track-origins=yes --leak-check=full ./linked_list Valgrind tells me this (I omitted the first part of the message that didn't really contain info):

0
1
2
3
4
5
==1366== 
==1366== HEAP SUMMARY:
==1366==     in use at exit: 29,618 bytes in 381 blocks
==1366==   total heap usage: 460 allocs, 79 frees, 35,650 bytes allocated
==1366== 
==1366== 80 (16 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 46 of 78
==1366==    at 0x6DFB: malloc (in /usr/local/Cellar/valgrind/3.9.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==1366==    by 0x100000E87: main (in ./linked_list)
==1366== 
==1366== LEAK SUMMARY:
==1366==    definitely lost: 16 bytes in 1 blocks
==1366==    indirectly lost: 64 bytes in 4 blocks
==1366==      possibly lost: 0 bytes in 0 blocks
==1366==    still reachable: 4,096 bytes in 1 blocks
==1366==         suppressed: 25,442 bytes in 375 blocks
==1366== Reachable blocks (those to which a pointer was found) are not shown.
==1366== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==1366== 
==1366== For counts of detected and suppressed errors, rerun with: -v
==1366== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 148 from 49)

I looked, and can't find the memory leak. I would love to know why this is happening, and what I can do in the future to prevent memory leaks. Thanks!