[PATCH] random32: Restore __latent_entropy attribute on net_rand_state
From: Thibaut Sautereau
Commit f227e3ec3b5c ("random32: update the net random state on interrupt
and activity") broke compilation and was temporarily fixed by Linus in
83bdc7275e62 ("random32: remove net_rand_state from the latent entropy
gcc plugin") by entirely moving net_rand_state out of the things handled
by the latent_entropy GCC plugin.
>From what I understand when reading the plugin code, using the
__latent_entropy attribute on a declaration was the wrong part and
simply keeping the __latent_entropy attribute on the variable definition
was the correct fix.
Fixes: 83bdc7275e62 ("random32: remove net_rand_state from the latent entropy
gcc plugin")
Cc: Linus Torvalds
Cc: Willy Tarreau
Cc: Emese Revfy
Signed-off-by: Thibaut Sautereau
---
lib/random32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/random32.c b/lib/random32.c
index 932345323af0..dfb9981ab798 100644
--- a/lib/random32.c
+++ b/lib/random32.c
@@ -49,7 +49,7 @@ static inline void prandom_state_selftest(void)
}
#endif
-DEFINE_PER_CPU(struct rnd_state, net_rand_state);
+DEFINE_PER_CPU(struct rnd_state, net_rand_state) __latent_entropy;
/**
* prandom_u32_state - seeded pseudo-random number generator.
--
2.28.0
Re: [RFC PATCH v8 0/3] Add support for AT_INTERPRETED (was O_MAYEXEC)
On Wed, Sep 09, 2020 at 06:08:51PM +0100, Matthew Wilcox wrote: > On Wed, Sep 09, 2020 at 09:19:11AM +0200, Mickaël Salaün wrote: > > > > On 08/09/2020 20:50, Al Viro wrote: > > > On Tue, Sep 08, 2020 at 09:59:53AM +0200, Mickaël Salaün wrote: > > >> Hi, > > >> > > >> This height patch series rework the previous O_MAYEXEC series by not > > >> adding a new flag to openat2(2) but to faccessat2(2) instead. As > > >> suggested, this enables to perform the access check on a file descriptor > > >> instead of on a file path (while opening it). This may require two > > >> checks (one on open and then with faccessat2) but it is a more generic > > >> approach [8]. > > > > > > Again, why is that folded into lookup/open/whatnot, rather than being > > > an operation applied to a file (e.g. O_PATH one)? > > > > I don't understand your question. AT_INTERPRETED can and should be used > > with AT_EMPTY_PATH. The two checks I wrote about was for IMA. > > Al is saying you should add a new syscall, not try to fold it into > some existing syscall. > > I agree with him. Add a new syscall, just like you were told to do it > last time. Sure, we'll do it. In the meantime, could we at least get an explanation about why using faccessat2() instead of a new syscall is wrong? I could see the reasons for separating the exec checks from the file opening, but this time I don't understand. Is it because it brings too much complexity to do_faccessat()? -- Thibaut Sautereau CLIP OS developer
Re: [PATCH v7 0/7] Add support for O_MAYEXEC
On Thu, Jul 23, 2020 at 07:12:20PM +0200, Mickaël Salaün wrote: > This patch series can be applied on top of v5.8-rc5 . v5.8-rc6, actually. > Previous version: > https://lore.kernel.org/lkml/20200505153156.925111-1-...@digikod.net/ This is v5. v6 is at https://lore.kernel.org/lkml/20200714181638.45751-1-...@digikod.net/ -- Thibaut Sautereau CLIP OS developer
Re: [PATCH v6 5/7] fs,doc: Enable to enforce noexec mounts or file exec through O_MAYEXEC
On Thu, Jul 16, 2020 at 04:39:14PM +0200, Mickaël Salaün wrote: > > On 15/07/2020 22:37, Kees Cook wrote: > > On Tue, Jul 14, 2020 at 08:16:36PM +0200, Mickaël Salaün wrote: > >> @@ -2849,7 +2855,7 @@ static int may_open(const struct path *path, int > >> acc_mode, int flag) > >>case S_IFLNK: > >>return -ELOOP; > >>case S_IFDIR: > >> - if (acc_mode & (MAY_WRITE | MAY_EXEC)) > >> + if (acc_mode & (MAY_WRITE | MAY_EXEC | MAY_OPENEXEC)) > >>return -EISDIR; > >>break; > > > > (I need to figure out where "open for reading" rejects S_IFDIR, since > > it's clearly not here...) Doesn't it come from generic_read_dir() in fs/libfs.c? > > > >>case S_IFBLK: > >> @@ -2859,13 +2865,26 @@ static int may_open(const struct path *path, int > >> acc_mode, int flag) > >>fallthrough; > >>case S_IFIFO: > >>case S_IFSOCK: > >> - if (acc_mode & MAY_EXEC) > >> + if (acc_mode & (MAY_EXEC | MAY_OPENEXEC)) > >>return -EACCES; > >>flag &= ~O_TRUNC; > >>break; > > > > This will immediately break a system that runs code with MAY_OPENEXEC > > set but reads from a block, char, fifo, or socket, even in the case of > > a sysadmin leaving the "file" sysctl disabled. > > As documented, O_MAYEXEC is for regular files. The only legitimate use > case seems to be with pipes, which should probably be allowed when > enforcement is disabled. By the way Kees, while we fix that for the next series, do you think it would be relevant, at least for the sake of clarity, to add a WARN_ON_ONCE(acc_mode & MAY_OPENEXEC) for the S_IFSOCK case, since a socket cannot be open anyway? -- Thibaut Sautereau CLIP OS developer
Re: NULL pointer dereference in coredump code
On Mon, Mar 30, 2020 at 10:31:59AM +0200, Thibaut Sautereau wrote:
> I hit a kernel NULL pointer dereference caused by the following call chain:
>
> do_coredump()
> file_start_write(cprm.file) # cprm.file is NULL
> file_inode(file) # NULL ptr deref
>
> The `ispipe` path is followed in do_coredump(), and:
> # cat /proc/sys/kernel/core_pattern
> |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
>
> It seems that cprm.file can be NULL after the call to the usermode
> helper, especially when setting CONFIG_STATIC_USERMODEHELPER=y and
> CONFIG_STATIC_USERMODEHELPER_PATH="", which is the case for me.
>
> One may say it's a strange combination of configuration options but I
> think it should not crash the kernel anyway. As I don't know much about
> coredumps in general and this code, I don't know what's the best way to
> fix this issue in a clean and comprehensive way.
>
> I attached the patch I used to temporarily work around this issue, if
> that can clarify anything.
>
> Thanks,
For the record, this had previously been reported [1] and was eventually
fixed by 3740d93e3790 ("coredump: fix crash when umh is disabled").
[1] https://bugzilla.kernel.org/show_bug.cgi?id=199795
--
Thibaut Sautereau
CLIP OS developer
NULL pointer deref in put_fs_context with unprivileged LXC
Since v5.1 and as of v5.3.5, I get the following oops every single time
I start an *unprivileged* LXC container:
BUG: kernel NULL pointer dereference, address: 0043
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD 0 P4D 0
Oops: [#1] SMP PTI
CPU: 3 PID: 3789 Comm: systemd Tainted: GT 5.3.5 #5
RIP: 0010:put_fs_context+0x13/0x180
Code: e4 31 c9 eb c8 e8 1d d6 dc ff 66 66 2e 0f 1f 84 00 00 00 00 00 66
90 41 54 55 48 89 fd 53 48 8b b>
RSP: 0018:c9777e10 EFLAGS: 00010286
RAX: fff3 RBX: RCX: c9777d6c
RDX: RSI: 8884062331e8 RDI: fff3
RBP: 8883e772dc00 R08: 88840d6bc680 R09: 0001
R10: R11: 0001 R12: fff3
R13: 888405ad2860 R14: 8883e772dc00 R15: 0027
FS: 7998d1444980() GS:88840f98()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0043 CR3: 00040d236003 CR4: 001606e0
Call Trace:
do_mount+0x2f6/0xab0
ksys_mount+0x79/0xc0
__x64_sys_mount+0x1d/0x30
do_syscall_64+0x68/0x666
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7998d23aafea
Code: 48 8b 0d a9 0e 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84
00 00 00 00 00 0f 1f 44 00 00 4>
RSP: 002b:7ffd4b0c8bc8 EFLAGS: 0246 ORIG_RAX: 00a5
RAX: ffda RBX: 5ae352a55a30 RCX: 7998d23aafea
RDX: 5ae3529fe0b3 RSI: 5ae3529fe0d5 RDI: 5ae3529fe0b3
RBP: 0007 R08: 5ae3529fe0ca R09: 5ae35433fb20
R10: 000e R11: 0246 R12: fffe
R13: R14: R15: 0001
Modules linked in:
CR2: 0043
---[ end trace 66de701522a6be46 ]---
RIP: 0010:put_fs_context+0x13/0x180
Code: e4 31 c9 eb c8 e8 1d d6 dc ff 66 66 2e 0f 1f 84 00 00 00 00 00 66
90 41 54 55 48 89 fd 53 48 8b b>
RSP: 0018:c9777e10 EFLAGS: 00010286
RAX: fff3 RBX: RCX: c9777d6c
RDX: RSI: 8884062331e8 RDI: fff3
RBP: 8883e772dc00 R08: 88840d6bc680 R09: 0001
R10: R11: 0001 R12: fff3
R13: 888405ad2860 R14: 8883e772dc00 R15: 0027
FS: 7998d1444980() GS:88840f98()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0043 CR3: 00040d236003 CR4: 001606e0
According to GDB:
$ gdb fs/fs_context.o
(gdb) l *put_fs_context+0x13
0xa53 is in put_fs_context (fs/fs_context.c:494).
489 void put_fs_context(struct fs_context *fc)
490 {
491 struct super_block *sb;
492
493 if (fc->root) {
494 sb = fc->root->d_sb;
495 dput(fc->root);
496 fc->root = NULL;
497 deactivate_super(sb);
498 }
$ gdb fs/namespace.o
(gdb) l *do_mount+0x2f6
0x5506 is in do_mount (fs/namespace.c:2796).
2791err = vfs_get_tree(fc);
2792if (!err)
2793err = do_new_mount_fc(fc, path, mnt_flags);
2794
2795put_fs_context(fc);
2796return err;
2797}
2798
2799int finish_automount(struct vfsmount *m, struct path *path)
2800{
I don't face this issue when starting the same container as a
privileged one. I tried to strace the container when launched in
foreground and the following snippet may be related to the problem:
[pid 35813] openat(AT_FDCWD, "/sys/fs",
O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = 4
[pid 35813] name_to_handle_at(4, "cgroup", {handle_bytes=128},
0x7ffcdf6ebac4, AT_SYMLINK_FOLLOW) = -1 EOPNOTSUPP (Operation not supported)
[pid 35813] name_to_handle_at(4, "", {handle_bytes=128},
0x7ffcdf6ebac4, AT_EMPTY_PATH) = -1 EOPNOTSUPP (Operation not supported)
[pid 35813] openat(4, "cgroup", O_RDONLY|O_CLOEXEC|O_PATH) = 5
[pid 35813] openat(AT_FDCWD, "/proc/self/fdinfo/5", O_RDONLY|O_CLOEXEC)
= 6
[pid 35813] fstat(6, {st_mode=S_IFREG|0400, st_size=0, ...}) = 0
[pid 35813] fstat(6, {st_mode=S_IFREG|0400, st_size=0, ...}) = 0
[pid 35813] read(6, "pos:\t0\nflags:\t01200\nmnt_id:\t"..., 2048) =
36
[pid 35813] read(6, "", 1024) = 0
[pid 35813]
Re: [PATCH v4] tpm: fix an invalid condition in tpm_common_poll
Hello Jarkko, On Thu, Mar 28, 2019 at 09:34:18AM -0700, Tadeusz Struk wrote: > On 3/28/19 5:34 AM, Jarkko Sakkinen wrote: > > Thank you, it is applied. > > Thank you Jarkko. What's the status of this patch now? It's needed in linux-5.0.y as TPM 2.0 support is currently broken with those stable kernels without this commit. Thanks, -- Thibaut
Re: [PATCH] blk-mq: fix a hung issue when fsync
On Wed, Jan 30, 2019 at 08:54:09AM -0700, Jens Axboe wrote: > On 1/30/19 2:01 AM, Jianchao Wang wrote: > > Florian reported a io hung issue when fsync(). It should be > > triggered by following race condition. > > > > data + post flush a flush > > > > blk_flush_complete_seq > > case REQ_FSEQ_DATA > > blk_flush_queue_rq > > issued to driver blk_mq_dispatch_rq_list > > try to issue a flush req > > failed due to NON-NCQ command > > .queue_rq return BLK_STS_DEV_RESOURCE > > > > request completion > > req->end_io // doesn't check RESTART > > mq_flush_data_end_io > > case REQ_FSEQ_POSTFLUSH > > blk_kick_flush > > do nothing because previous flush > > has not been completed > > blk_mq_run_hw_queue > > insert rq to hctx->dispatch > > due to RESTART is still set, do nothing > > > > To fix this, replace the blk_mq_run_hw_queue in mq_flush_data_end_io > > with blk_mq_sched_restart to check and clear the RESTART flag. > > Applied, thanks. > > -- > Jens Axboe Can this be applied to stable kernels please? It's commit 85bd6e61f34dffa8ec2dc75ff3c02ee7b2f1cbce upstream. Thanks, -- Thibaut
[PATCH] lib: fix three typos in Kconfig help text
Fix three typos in CONFIG_WARN_ALL_UNSEEDED_RANDOM help text. Signed-off-by: Thibaut Sautereau --- lib/Kconfig.debug | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index c7fef0c56d6b..3e50cc93572c 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1277,13 +1277,13 @@ config WARN_ALL_UNSEEDED_RANDOM time. This is really bad from a security perspective, and so architecture maintainers really need to do what they can to get the CRNG seeded sooner after the system is booted. - However, since users can not do anything actionble to + However, since users cannot do anything actionable to address this, by default the kernel will issue only a single warning for the first use of unseeded randomness. Say Y here if you want to receive warnings for all uses of unseeded randomness. This will be of use primarily for - those developers interersted in improving the security of + those developers interested in improving the security of Linux kernels running on their architecture (or subarchitecture). -- 2.18.0
[PATCH] lib: fix three typos in Kconfig help text
Fix three typos in CONFIG_WARN_ALL_UNSEEDED_RANDOM help text. Signed-off-by: Thibaut Sautereau --- lib/Kconfig.debug | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index c7fef0c56d6b..3e50cc93572c 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1277,13 +1277,13 @@ config WARN_ALL_UNSEEDED_RANDOM time. This is really bad from a security perspective, and so architecture maintainers really need to do what they can to get the CRNG seeded sooner after the system is booted. - However, since users can not do anything actionble to + However, since users cannot do anything actionable to address this, by default the kernel will issue only a single warning for the first use of unseeded randomness. Say Y here if you want to receive warnings for all uses of unseeded randomness. This will be of use primarily for - those developers interersted in improving the security of + those developers interested in improving the security of Linux kernels running on their architecture (or subarchitecture). -- 2.18.0
