From: Christian Brauner <brauner@xxxxxxxxxx>
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.
