Re: [PATCH RFC 3/3] coredump: support AF_UNIX sockets

[Kuniyuki Iwashima <kuniyu@amazon.com>]

From: Christian Brauner <brauner@kernel.org>
Date: Wed, 30 Apr 2025 13:05:03 +0200
> @@ -801,6 +837,49 @@ void do_coredump(const kernel_siginfo_t *siginfo)
>  		}
>  		break;
>  	}
> +	case COREDUMP_SOCK: {
> +		struct file *file __free(fput) = NULL;
> +		struct sockaddr_un unix_addr = {
> +			.sun_family = AF_UNIX,
> +		};
> +		struct sockaddr_storage *addr;
> +
> +		retval = strscpy(unix_addr.sun_path, cn.corename, sizeof(unix_addr.sun_path));
> +		if (retval < 0)
> +			goto close_fail;
> +
> +		file = __sys_socket_file(AF_UNIX, SOCK_STREAM, 0);
> +		if (IS_ERR(file))
> +			goto close_fail;
> +
> +		/*
> +		 * It is possible that the userspace process which is
> +		 * supposed to handle the coredump and is listening on
> +		 * the AF_UNIX socket coredumps. This should be fine
> +		 * though. If this was the only process which was
> +		 * listen()ing on the AF_UNIX socket for coredumps it
> +		 * obviously won't be listen()ing anymore by the time it
> +		 * gets here. So the __sys_connect_file() call will
> +		 * often fail with ECONNREFUSED and the coredump.
> +		 *
> +		 * In general though, userspace should just mark itself
> +		 * non dumpable and not do any of this nonsense. We
> +		 * shouldn't work around this.
> +		 */
> +		addr = (struct sockaddr_storage *)(&unix_addr);
> +		retval = __sys_connect_file(file, addr, sizeof(unix_addr), O_CLOEXEC);

The 3rd argument should be offsetof(struct sockaddr_un, sun_path)
+ retval of strscpy() above ?

I guess you could see an unexpected error when
CONFIG_INIT_STACK_NONE=y and cn.corename has garbage at tail.