kernel/git/stable/linux.git/fs/pstore, branch linux-6.7.y

pstore: inode: Only d_invalidate() is needed

2024-03-26T22:18:20+00:00

[ Upstream commit a43e0fc5e9134a46515de2f2f8d4100b74e50de3 ] Unloading a modular pstore backend with records in pstorefs would trigger the dput() double-drop warning: WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410 Using the combo of d_drop()/dput() (as mentioned in Documentation/filesystems/vfs.rst) isn't the right approach here, and leads to the reference counting problem seen above. Use d_invalidate() and update the code to not bother checking for error codes that can never happen. Suggested-by: Alexander Viro Fixes: 609e28bb139e ("pstore: Remove filesystem records when backend is unregistered") Signed-off-by: Kees Cook

pstore: inode: Convert mutex usage to guard(mutex)

2024-03-26T22:18:19+00:00

[ Upstream commit e2eeddefb046dbc771a6fa426f7f98fb25adfe68 ] Replace open-coded mutex handling with cleanup.h guard(mutex) and scoped_guard(mutex, ...). Cc: Guilherme G. Piccoli Cc: Tony Luck Cc: Link: https://lore.kernel.org/r/20231205182622.1329923-2-keescook@chromium.org Signed-off-by: Kees Cook Stable-dep-of: a43e0fc5e913 ("pstore: inode: Only d_invalidate() is needed") Signed-off-by: Sasha Levin

pstore/ram: Fix crash when setting number of cpus to an odd number

2024-02-05T20:16:47+00:00

[ Upstream commit d49270a04623ce3c0afddbf3e984cb245aa48e9c ] When the number of cpu cores is adjusted to 7 or other odd numbers, the zone size will become an odd number. The address of the zone will become: addr of zone0 = BASE addr of zone1 = BASE + zone_size addr of zone2 = BASE + zone_size*2 ... The address of zone1/3/5/7 will be mapped to non-alignment va. Eventually crashes will occur when accessing these va. So, use ALIGN_DOWN() to make sure the zone size is even to avoid this bug. Signed-off-by: Weichen Chen Reviewed-by: Matthias Brugger Tested-by: "Guilherme G. Piccoli" Link: https://lore.kernel.org/r/20230224023632.6840-1-weichen.chen@mediatek.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin

pstore: ram_core: fix possible overflow in persistent_ram_init_ecc()

2024-01-25T23:44:42+00:00

[ Upstream commit 86222a8fc16ec517de8da2604d904c9df3a08e5d ] In persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return 64-bit value since persistent_ram_zone::buffer_size has type size_t which is derived from the 64-bit *unsigned long*, while the ecc_blocks variable this value gets assigned to has (always 32-bit) *int* type. Even if that value fits into *int* type, an overflow is still possible when calculating the size_t typed ecc_total variable further below since there's no cast to any 64-bit type before multiplication. Declaring the ecc_blocks variable as *size_t* should fix this mess... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Fixes: 9cc05ad97c57 ("staging: android: persistent_ram: refactor ecc support") Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/20231105202936.25694-1-s.shtylyov@omp.ru Signed-off-by: Kees Cook Signed-off-by: Sasha Levin

Merge tag 'pstore-v6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2023-10-31T05:26:39+00:00

Pull pstore updates from Kees Cook: - Check for out-of-memory condition during initialization (Jiasheng Jiang) - Fix documentation typos (Tudor Ambarus) * tag 'pstore-v6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: pstore/platform: Add check for kstrdup docs: pstore-blk.rst: fix typo, s/console/ftrace docs: pstore-blk.rst: use "about" as a preposition after "care"

pstore: convert to new timestamp accessors

2023-10-18T12:08:26+00:00

Convert to using the new inode timestamp accessor functions. Signed-off-by: Jeff Layton Link: https://lore.kernel.org/r/20231004185347.80880-60-jlayton@kernel.org Acked-by: Kees Cook Signed-off-by: Christian Brauner

pstore/platform: Add check for kstrdup

2023-10-12T16:47:01+00:00

Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. Fixes: 563ca40ddf40 ("pstore/platform: Switch pstore_info::name to const") Signed-off-by: Jiasheng Jiang Link: https://lore.kernel.org/r/20230623022706.32125-1-jiasheng@iscas.ac.cn Signed-off-by: Kees Cook

Merge tag 'pstore-v6.6-rc1-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2023-09-02T17:45:17+00:00

Pull pstore fix from Kees Cook: - Adjust sizes of buffers just avoid uncompress failures (Ard Biesheuvel) * tag 'pstore-v6.6-rc1-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: pstore: Base compression input buffer size on estimated compressed size

pstore: Base compression input buffer size on estimated compressed size

2023-08-31T20:58:49+00:00

Commit 1756ddea6916 ("pstore: Remove worst-case compression size logic") removed some clunky per-algorithm worst case size estimation routines on the basis that we can always store pstore records uncompressed, and these worst case estimations are about how much the size might inadvertently *increase* due to encapsulation overhead when the input cannot be compressed at all. So if compression results in a size increase, we just store the original data instead. However, it seems that the original code was misinterpreting these calculations as an estimation of how much uncompressed data might fit into a compressed buffer of a given size, and it was using the results to consume the input data in larger chunks than the pstore record size, relying on the compression to ensure that what ultimately gets stored fits into the available space. One result of this, as observed and reported by Linus, is that upgrading to a newer kernel that includes the given commit may result in pstore decompression errors reported in the kernel log. This is due to the fact that the existing records may unexpectedly decompress to a size that is larger than the pstore record size. Another potential problem caused by this change is that we may underutilize the fixed sized records on pstore backends such as ramoops. And on pstore backends with variable sized records such as EFI, we will end up creating many more entries than before to store the same amount of compressed data. So let's fix both issues, by bringing back the typical case estimation of how much ASCII text captured from the dmesg log might fit into a pstore record of a given size after compression. The original implementation used the computation given below for zlib: switch (size) { /* buffer range for efivars */ case 1000 ... 2000: cmpr = 56; break; case 2001 ... 3000: cmpr = 54; break; case 3001 ... 3999: cmpr = 52; break; /* buffer range for nvram, erst */ case 4000 ... 10000: cmpr = 45; break; default: cmpr = 60; break; } return (size * 100) / cmpr; We will use the previous worst-case of 60% for compression. For decompression go extra large (3x) so we make sure there's enough space for anything. While at it, rate limit the error message so we don't flood the log unnecessarily on systems that have accumulated a lot of pstore history. Cc: Linus Torvalds Cc: Eric Biggers Cc: Kees Cook Cc: Herbert Xu Signed-off-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20230830212238.135900-1-ardb@kernel.org Co-developed-by: Kees Cook Signed-off-by: Kees Cook

Merge tag 'pstore-v6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2023-08-28T19:36:04+00:00

Pull pstore updates from Kees Cook: - Greatly simplify compression support (Ard Biesheuvel) - Avoid crashes for corrupted offsets when prz size is 0 (Enlin Mu) - Expand range of usable record sizes (Yuxiao Zhang) - Fix kernel-doc warning (Matthew Wilcox) * tag 'pstore-v6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: pstore: Fix kernel-doc warning pstore: Support record sizes larger than kmalloc() limit pstore/ram: Check start of empty przs during init pstore: Replace crypto API compression with zlib_deflate library calls pstore: Remove worst-case compression size logic