linux-kernel - Re: [PATCH RFC 3/3] coredump: support AF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250501003048.49502-1-kuniyu@amazon.com>
Date: Wed, 30 Apr 2025 17:25:19 -0700
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <brauner@...nel.org>
CC: <bluca@...ian.org>, <daan.j.demeyer@...il.com>, <davem@...emloft.net>,
	<david@...dahead.eu>, <edumazet@...gle.com>, <horms@...nel.org>,
	<jack@...e.cz>, <kuba@...nel.org>, <kuniyu@...zon.com>,
	<lennart@...ttering.net>, <linux-fsdevel@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <me@...dnzj.com>, <netdev@...r.kernel.org>,
	<oleg@...hat.com>, <pabeni@...hat.com>, <viro@...iv.linux.org.uk>,
	<zbyszek@...waw.pl>
Subject: Re: [PATCH RFC 3/3] coredump: support AF_UNIX sockets

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