Создание и тестирование Firewall в Linux, Часть 1.3. Написание char device. Добавление виртуальной файловой системы…

static ssize_t fw_device_read(struct file* filp, char __user *buffer, size_t length, loff_t* offset)
{
	printk("Reading from device, return total number of messages\n");
	return sprintf(buffer, "%u", accepted_num + dropped_num); 
}

При использовании printk строка формата должна начинаться с одного из макросов KERN_*, определяющих уровень важности сообщения, или с KERN_CONT, если нужно продолжить с последним использованным уровнем важности.

Но это несущественная ошибка, в отличие от sprintf в пользовательский буфер.

Что будет, если пользователь передаст в параметре buffer невалидный пользовательский адрес?
Или что будет, если пользователь передаст в параметре buffer виртуальный адрес где-нибудь в области данных ядра?
В первом случае приложение будет завершено с SIGSEGV и сообщением ядра о недопустимом обращении ядра к виртуальному адресу, хотя достаточно было бы одного SIGSEGV.
Во втором случае память ядра будет перезаписана вашей строкой, что вряд ли закончится хорошо.

Для безопасного копирования данных в/из пространства пользователя есть функции copy_to_user и copy_from_user, а так же strlen_user/strnlen_user/strncpy_from_user.

Кроме того, вы проигнорировали параметр length, из-за чего в следующем фрагменте пользовательского кода происходит переполнение буфера msg:

int all_msg() {
	char msg[1] = {0};
	int fd = open("/dev/device_fw", O_RDONLY);
	if (fd<0) {
		printf("Device access error, fd = %d\n", fd);
		return fd;
	}

	if(read(fd, &msg, 1)>0){	
		printf("Accepted packets number: %s\n", msg);
	} else {
		printf("Nothing to read\n");
	}

	close(fd);
	return 0;
}

static ssize_t fw_device_write(struct file *fp, const char *buff, size_t length, loff_t *ppos) 

Второй параметр этой функции тоже имеет атрибут __user.

Правильность использования атрибута __user можно проверить, передав параметр C=1 команде make собирающей модуль.

мы не используем goto в программировании, потому что это очень сильно портит понимание, содержание, читаемость кода

Каким таким загадочно-непостижимым образом явное указание перехода на определенную метку может испортить понимание, содержание и читаемость кода???? Не понимаю…
Второе. Для того чтобы программа заработала(а не делала вид, что она что-то там делает) программист должен учесть все возможные ситуации при работе с программой, как то — ввод символьных данных вместо цифровых, длина вводимой строки, и т.д. и т.п. То есть он должен понимать что он делает и для чего. И тогда «дыр» в программах будет гораздо меньше. Хотя я совершенно не понимаю как можно писать программу(например) для работы с электронной почтой, а потом использовать её для доступа к файлам с паролями. Как по мне это очень сильно постараться нужно так сделать. Ну в смысле накосячить.
Как говориться «Проверьте свою программу на ошибки. Если в вашей программе их нет, то проверьте программу еще раз. Если снова ошибки не найдены, то вы плохой программист»