aboutsummaryrefslogtreecommitdiffstats
path: root/lib/crypto/mpi/mpicoder.c
diff options
context:
space:
mode:
authorJakub Kicinski <[email protected]>2025-07-11 00:11:21 +0000
committerJakub Kicinski <[email protected]>2025-07-11 14:31:47 +0000
commita215b5723922f8099078478122f02100e489cb80 (patch)
tree9d884289283dd7e7c27fe6102b50977bf59983d1 /lib/crypto/mpi/mpicoder.c
parentnetlink: Fix rmem check in netlink_broadcast_deliver(). (diff)
downloadkernel-a215b5723922f8099078478122f02100e489cb80.tar.gz
kernel-a215b5723922f8099078478122f02100e489cb80.zip
netlink: make sure we allow at least one dump skb
Commit under Fixes tightened up the memory accounting for Netlink sockets. Looks like the accounting is too strict for some existing use cases, Marek reported issues with nl80211 / WiFi iw CLI. To reduce number of iterations Netlink dumps try to allocate messages based on the size of the buffer passed to previous recvmsg() calls. If user space uses a larger buffer in recvmsg() than sk_rcvbuf we will allocate an skb we won't be able to queue. Make sure we always allow at least one skb to be queued. Same workaround is already present in netlink_attachskb(). Alternative would be to cap the allocation size to rcvbuf - rmem_alloc but as I said, the workaround is already present in other places. Reported-by: Marek Szyprowski <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: ae8f160e7eb2 ("netlink: Fix wraparounds of sk->sk_rmem_alloc.") Tested-by: Marek Szyprowski <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
Diffstat (limited to 'lib/crypto/mpi/mpicoder.c')
0 files changed, 0 insertions, 0 deletions