laptop-kernel/lib, branch master

Merge tag 'libcrypto-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux

2026-10-14T15:23:37Z

Pull crypto library fixes from Eric Biggers: "Fix two Poly1305 bugs including a lost carry bit, and add a regression test" * tag 'libcrypto-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: lib/crypto: tests: Add Poly1305 split-update carry regression test lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON state lib/crypto: poly1305: Use memzero_explicit() in poly1305_final()

lib/crypto: tests: Add Poly1305 split-update carry regression test

2026-10-09T17:21:07Z

Add a test case which reproduces the bug fixed by commit 24f07e8c07a0 ("lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON state"). It is written in a fairly general way, such that it should also be able to reproduce similar bugs in other implementations. Update the comment on test_poly1305_allones_keys_and_message() to more accurately describe what it does and differentiate it from the new test. Reviewed-by: Jason A. Donenfeld Link: https://patch.msgid.link/20261009125354.315476-3-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON state

2026-10-09T17:20:29Z

When poly1305_blocks_neon() resumes from a base 2^26 accumulator and the next update contains an odd number of full 16-byte blocks, it processes one leading block through poly1305_mult() so that the remaining NEON work has an even block count. That requires converting the accumulator to the base 2^64 form used by poly1305_mult(). The final ADC of that conversion stores the carry into d2, but the following accumulation and poly1305_mult() use h2. If the conversion carries across bit 128, the carry is dropped and the emitted tag is wrong. This was introduced by Cryptogams commit 03dc4adf91c8 ("arm/poly1305-armv*.pl: optimize branches."), which removed the reduction that consumed d2 shortly before Linux imported the code. OpenSSL's copy did not take that change. The carry is possible because the NEON code stores the accumulator [h0, h1, h2, h3, h4] in a lazily reduced, redundant base 2^26 form: its final carry chain leaves h0, h2, h3 < 2^26, but h1 and h4 may slightly exceed 2^26 - 1. For example, the reachable state h0 = 4 h1 = 2^26 h2 = 2^26 - 1 h3 = 2^26 - 1 h4 = 2^24 - 1 represents 4 + 2^26*2^26 + (2^26-1)*2^52 + (2^26-1)*2^78 + (2^24-1)*2^104 = 2^128 + 4, despite the bit representing the 2^128 term (bit 24 of h4) not being set; the extra comes from the h1 limb being above the normal base 2^26 range. When this value is converted into the non-redundant base 2^64 form, a carry into the new 2^128 bit (in bit 0 of h2) is necessary to preserve the value. Given the above bounds, a carry into bit 128 happens exactly when h1 >= 2^26, h2 = h3 = 2^26 - 1, and h4 mod 2^24 = 2^24 - 1. Store the carry into h2, matching the other base 2^26 to base 2^64 conversions in poly1305_blocks() and poly1305_emit(). This bug causes an incorrect tag to be emitted. However, this is unlikely to happen in practice where Poly1305 is used with a random key, since the random key tends to distribute the accumulator values throughout their valid range. There isn't an obvious way for an attacker without knowledge of the r_key to cause [h0, h1, h2, h3, h4] to land on the precise values where this bug occurs. [EB: Rewrote the commit message to more clearly describe the bug and its impact, and simplified explanation about why there's a carry bit.] Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS NEON implementation") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Jason A. Donenfeld Signed-off-by: Jérémy Jean Link: https://patch.msgid.link/20261009125354.315476-2-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: poly1305: Use memzero_explicit() in poly1305_final()

2026-10-09T17:20:29Z

Use memzero_explicit() instead of a plain struct assignment to guarantee zeroization of the 'struct poly1305_desc_ctx'. Note that dead store elimination was only theoretically possible with link-time optimization here. But it's still worth fixing. Fixes: a1d93064094c ("crypto: poly1305 - expose init/update/final library interface") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/bug/linux-c3a6bd76-f6ab-4203-892a-cd06f7aa0c34 Reviewed-by: Ard Biesheuvel Link: https://patch.msgid.link/20261006083432.16328-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/dim: add KUnit test for dim_calc_stats()

2026-10-02T06:52:31Z

Add a KUnit suite for the DIM library that checks the packet, byte, event and completion rates computed by dim_calc_stats(), including counter wraparound and windows whose byte or packet count times USEC_PER_MSEC does not fit in 32 bits. The latter cases fail on 32-bit architectures without the previous commit. Assisted-by: LLM Signed-off-by: Shashank Mohan Jain Signed-off-by: David S. Miller

lib/dim: fix 32-bit overflow in dim_calc_stats() rates

2026-10-02T06:52:31Z

dim_calc_stats() computes the per-millisecond rates as DIV_ROUND_UP(nbytes * USEC_PER_MSEC, delta_us) where nbytes is a u32 and USEC_PER_MSEC is 1000L. On 64-bit the product is done in 64-bit long arithmetic, but on 32-bit architectures long is 32 bits wide and the product wraps as soon as a measurement window carries more than 4294967 bytes (about 4.3 MB). The same applies to the packet and completion counts, although those need more than 4.29 million packets or completions per window. A DIM window spans DIM_NEVENTS (64) events. Drivers count events per interrupt or per NAPI poll, so under sustained load a window can easily carry more than 4.3 MB: 64 full NAPI polls of 64 MTU-sized frames are already 6.2 MB, and drivers such as mtk_eth_soc count one event per interrupt while NAPI keeps polling with the interrupt masked. On 32-bit users of the library (for example mtk_eth_soc on MT7621, bcmgenet and bcmsysport on 32-bit ARM, or virtio_net in a 32-bit guest) bpms then becomes the product modulo 2^32 divided by the window length, and net_dim_stats_compare() makes its BETTER/WORSE decisions on a value that has little to do with the real throughput. For example, a 1 Gbit/s link at line rate that moves 5 MB in a 40 ms window gives bpms = 125000 on 64-bit but 17626 on 32-bit, and 5 million packets in 2 s gives ppms = 353 instead of 2500. Widen the products to 64 bits and divide with DIV_ROUND_UP_ULL(). The results are unchanged on 64-bit. Fixes: cb3c7fd4f839 ("net/mlx5e: Support adaptive RX coalescing") Fixes: 4c4dbb4a7363 ("net/mlx5e: Move dynamic interrupt coalescing code to include/linux") Assisted-by: LLM Signed-off-by: Shashank Mohan Jain Signed-off-by: David S. Miller

Merge tag 'mm-hotfixes-stable-2026-09-13-21-50' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

2026-09-14T15:59:09Z

Pull misc fixes from Andrew Morton: "14 hotfixes. 10 are cc:stable. 11 are for MM. All are singletons - please see the changelogs for details" * tag 'mm-hotfixes-stable-2026-09-13-21-50' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/folio: EXPORT_SYMBOL_FOR_KVM(lru_cache_drain_for_folio) mm/shrinker: fix bogus set_shrinker_bit() with cgroup.memory=nokmem mm/vma: correctly unaccount on mmap_prepare() failure mm/mlock: use the IRQ-safe accessor for NR_MLOCK in __munlock_folio() remove old lib/alloc_tag.c fs/dax: check zero or empty entry before converting xarray entry fs: fix missed removal of super_fs_objects_eligible() mm: filemap: retain mapped dropbehind folios mailmap: update entry for Christopher Obbard memcg: avoid charging the root memcg from obj_cgroup_charge_pages() mm, swap: fix SWAP_USAGE_OFFLIST_BIT collision with real usage count mailmap: map Coiby Xu's address mm/mremap: account mm->locked_vm correctly for MREMAP_DONTUNMAP mm/huge_memory: bypass THP tuneables for huge pfnmap mappings

Merge tag 'block-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux

2026-09-11T19:38:44Z

Pull block fixes from Jens Axboe: - Fix the start and length check added to iov_iter_extract_bvecs(), which used iter_iov_addr()/iter_iov_len() helpers that aren't safe for the ITER_BVEC/FOLIOQ/etc iterator types passed - sunvdc fixes for an -EIO issue from lack of retries, and unmapping LDC cookies when the descriptor send fails - Clear force_abort in ublk_queue_reset_io_flags() - ublk selftest install fix * tag 'block-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: selftests: ublk: add batch IO cases to recover_03 ublk: clear force_abort in ublk_queue_reset_io_flags() sunvdc: fix -EIO issue due to lack of retries sunvdc: unmap LDC cookies when the descriptor send fails block: Fix start and length check added to iov_iter_extract_bvecs() selftests: ublk: install test_common.sh and trace/ scripts

block: Fix start and length check added to iov_iter_extract_bvecs()

2026-09-10T20:44:39Z

Commit 14b007e17881 added an address check using iter_iov_addr() and a length check using iter_iov_len() to iov_iter_extract_bvecs(), but these cannot be used so and are unsafe in this circumstance as the functions have hardwired assumptions about the iterator type. They should only be used with ITER_UBUF or ITER_IOVEC-type iterators; they shouldn't be used with ITER_BVEC, ITER_KVEC, ITER_FOLIOQ, ITER_XARRAY or ITER_DISCARD iterators. This proves to be a problem for cachefiles as an iterator of type ITER_FOLIOQ is passed and iter_iov_addr() and iter_iov_len() both malfunction because iter->__iov in iter_iov() is not pointing to an iovec array. Fix this by using iov_iter_alignment() instead. Fixes: 14b007e17881 ("block: validate user space vectors during extraction") Signed-off-by: David Howells Reviewed-by: Keith Busch cc: Hannes Reinecke cc: Christoph Hellwig cc: Jens Axboe cc: Alexander Viro cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-block@vger.kernel.org cc: linux-fsdevel@vger.kernel.org Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/1667275.1788941191@warthog.procyon.org.uk Signed-off-by: Jens Axboe

remove old lib/alloc_tag.c

2026-09-05T18:47:49Z

This was moved into mm/, but the original lib/ file somehow remained. Remove it. Reported-by: Suren Baghdasaryan Cc: Lorenzo Stoakes Signed-off-by: Andrew Morton