From: Greg Kroah-Hartman Date: Thu, 5 Sep 2024 08:15:12 +0000 (+0200) Subject: 5.4-stable patches X-Git-Tag: v6.1.109~15 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=1fa00971109067fd9c176989b9dcba283e0d533e;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: block-initialize-integrity-buffer-to-zero-before-writing-it-to-media.patch net-set-sock_rcu_free-before-inserting-socket-into-hashtable.patch udf-limit-file-size-to-4tb.patch virtio_net-fix-napi_skb_cache_put-warning.patch --- diff --git a/queue-5.4/block-initialize-integrity-buffer-to-zero-before-writing-it-to-media.patch b/queue-5.4/block-initialize-integrity-buffer-to-zero-before-writing-it-to-media.patch new file mode 100644 index 00000000000..91c4ec1ae6d --- /dev/null +++ b/queue-5.4/block-initialize-integrity-buffer-to-zero-before-writing-it-to-media.patch @@ -0,0 +1,61 @@ +From 899ee2c3829c5ac14bfc7d3c4a5846c0b709b78f Mon Sep 17 00:00:00 2001 +From: Christoph Hellwig +Date: Thu, 13 Jun 2024 10:48:11 +0200 +Subject: block: initialize integrity buffer to zero before writing it to media + +From: Christoph Hellwig + +commit 899ee2c3829c5ac14bfc7d3c4a5846c0b709b78f upstream. + +Metadata added by bio_integrity_prep is using plain kmalloc, which leads +to random kernel memory being written media. For PI metadata this is +limited to the app tag that isn't used by kernel generated metadata, +but for non-PI metadata the entire buffer leaks kernel memory. + +Fix this by adding the __GFP_ZERO flag to allocations for writes. + +Fixes: 7ba1ba12eeef ("block: Block layer data integrity support") +Signed-off-by: Christoph Hellwig +Reviewed-by: Martin K. Petersen +Reviewed-by: Kanchan Joshi +Reviewed-by: Chaitanya Kulkarni +Link: https://lore.kernel.org/r/20240613084839.1044015-2-hch@lst.de +Signed-off-by: Jens Axboe +Signed-off-by: Shivani Agarwal +Signed-off-by: Greg Kroah-Hartman +--- + block/bio-integrity.c | 11 ++++++++++- + 1 file changed, 10 insertions(+), 1 deletion(-) + +--- a/block/bio-integrity.c ++++ b/block/bio-integrity.c +@@ -212,6 +212,7 @@ bool bio_integrity_prep(struct bio *bio) + unsigned int bytes, offset, i; + unsigned int intervals; + blk_status_t status; ++ gfp_t gfp = GFP_NOIO; + + if (!bi) + return true; +@@ -234,12 +235,20 @@ bool bio_integrity_prep(struct bio *bio) + if (!bi->profile->generate_fn || + !(bi->flags & BLK_INTEGRITY_GENERATE)) + return true; ++ ++ /* ++ * Zero the memory allocated to not leak uninitialized kernel ++ * memory to disk. For PI this only affects the app tag, but ++ * for non-integrity metadata it affects the entire metadata ++ * buffer. ++ */ ++ gfp |= __GFP_ZERO; + } + intervals = bio_integrity_intervals(bi, bio_sectors(bio)); + + /* Allocate kernel buffer for protection data */ + len = intervals * bi->tuple_size; +- buf = kmalloc(len, GFP_NOIO | q->bounce_gfp); ++ buf = kmalloc(len, gfp | q->bounce_gfp); + status = BLK_STS_RESOURCE; + if (unlikely(buf == NULL)) { + printk(KERN_ERR "could not allocate integrity buffer\n"); diff --git a/queue-5.4/net-set-sock_rcu_free-before-inserting-socket-into-hashtable.patch b/queue-5.4/net-set-sock_rcu_free-before-inserting-socket-into-hashtable.patch new file mode 100644 index 00000000000..6517558c90d --- /dev/null +++ b/queue-5.4/net-set-sock_rcu_free-before-inserting-socket-into-hashtable.patch @@ -0,0 +1,87 @@ +From 871019b22d1bcc9fab2d1feba1b9a564acbb6e99 Mon Sep 17 00:00:00 2001 +From: Stanislav Fomichev +Date: Wed, 8 Nov 2023 13:13:25 -0800 +Subject: net: set SOCK_RCU_FREE before inserting socket into hashtable + +From: Stanislav Fomichev + +commit 871019b22d1bcc9fab2d1feba1b9a564acbb6e99 upstream. + +We've started to see the following kernel traces: + + WARNING: CPU: 83 PID: 0 at net/core/filter.c:6641 sk_lookup+0x1bd/0x1d0 + + Call Trace: + + __bpf_skc_lookup+0x10d/0x120 + bpf_sk_lookup+0x48/0xd0 + bpf_sk_lookup_tcp+0x19/0x20 + bpf_prog_+0x37c/0x16a3 + cls_bpf_classify+0x205/0x2e0 + tcf_classify+0x92/0x160 + __netif_receive_skb_core+0xe52/0xf10 + __netif_receive_skb_list_core+0x96/0x2b0 + napi_complete_done+0x7b5/0xb70 + _poll+0x94/0xb0 + net_rx_action+0x163/0x1d70 + __do_softirq+0xdc/0x32e + asm_call_irq_on_stack+0x12/0x20 + + do_softirq_own_stack+0x36/0x50 + do_softirq+0x44/0x70 + +__inet_hash can race with lockless (rcu) readers on the other cpus: + + __inet_hash + __sk_nulls_add_node_rcu + <- (bpf triggers here) + sock_set_flag(SOCK_RCU_FREE) + +Let's move the SOCK_RCU_FREE part up a bit, before we are inserting +the socket into hashtables. Note, that the race is really harmless; +the bpf callers are handling this situation (where listener socket +doesn't have SOCK_RCU_FREE set) correctly, so the only +annoyance is a WARN_ONCE. + +More details from Eric regarding SOCK_RCU_FREE timeline: + +Commit 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt under +synflood") added SOCK_RCU_FREE. At that time, the precise location of +sock_set_flag(sk, SOCK_RCU_FREE) did not matter, because the thread calling +__inet_hash() owns a reference on sk. SOCK_RCU_FREE was only tested +at dismantle time. + +Commit 6acc9b432e67 ("bpf: Add helper to retrieve socket in BPF") +started checking SOCK_RCU_FREE _after_ the lookup to infer whether +the refcount has been taken care of. + +Fixes: 6acc9b432e67 ("bpf: Add helper to retrieve socket in BPF") +Reviewed-by: Eric Dumazet +Signed-off-by: Stanislav Fomichev +Reviewed-by: Kuniyuki Iwashima +Signed-off-by: David S. Miller +[Resolved conflict for 5.10 and below.] +Signed-off-by: Siddh Raman Pant +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv4/inet_hashtables.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/ipv4/inet_hashtables.c ++++ b/net/ipv4/inet_hashtables.c +@@ -609,6 +609,7 @@ int __inet_hash(struct sock *sk, struct + if (err) + goto unlock; + } ++ sock_set_flag(sk, SOCK_RCU_FREE); + if (IS_ENABLED(CONFIG_IPV6) && sk->sk_reuseport && + sk->sk_family == AF_INET6) + __sk_nulls_add_node_tail_rcu(sk, &ilb->nulls_head); +@@ -616,7 +617,6 @@ int __inet_hash(struct sock *sk, struct + __sk_nulls_add_node_rcu(sk, &ilb->nulls_head); + inet_hash2(hashinfo, sk); + ilb->count++; +- sock_set_flag(sk, SOCK_RCU_FREE); + sock_prot_inuse_add(sock_net(sk), sk->sk_prot, 1); + unlock: + spin_unlock(&ilb->lock); diff --git a/queue-5.4/series b/queue-5.4/series index 2ef8ea842fe..707673e7675 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -18,3 +18,7 @@ smack-tcp-ipv4-fix-incorrect-labeling.patch wifi-cfg80211-make-hash-table-duplicates-more-surviv.patch drm-amd-display-skip-wbscl_set_scaler_filter-if-filt.patch media-uvcvideo-enforce-alignment-of-frame-and-interv.patch +block-initialize-integrity-buffer-to-zero-before-writing-it-to-media.patch +net-set-sock_rcu_free-before-inserting-socket-into-hashtable.patch +virtio_net-fix-napi_skb_cache_put-warning.patch +udf-limit-file-size-to-4tb.patch diff --git a/queue-5.4/udf-limit-file-size-to-4tb.patch b/queue-5.4/udf-limit-file-size-to-4tb.patch new file mode 100644 index 00000000000..259e4683022 --- /dev/null +++ b/queue-5.4/udf-limit-file-size-to-4tb.patch @@ -0,0 +1,46 @@ +From c2efd13a2ed4f29bf9ef14ac2fbb7474084655f8 Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Wed, 25 Jan 2023 17:56:06 +0100 +Subject: udf: Limit file size to 4TB + +From: Jan Kara + +commit c2efd13a2ed4f29bf9ef14ac2fbb7474084655f8 upstream. + +UDF disk format supports in principle file sizes up to 1<<64-1. However +the file space (including holes) is described by a linked list of +extents, each of which can have at most 1GB. Thus the creation and +handling of extents gets unusably slow beyond certain point. Limit the +file size to 4TB to avoid locking up the kernel too easily. + +Signed-off-by: Jan Kara +Signed-off-by: Greg Kroah-Hartman +--- + fs/udf/super.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/fs/udf/super.c ++++ b/fs/udf/super.c +@@ -86,6 +86,13 @@ enum { + #define UDF_MAX_LVID_NESTING 1000 + + enum { UDF_MAX_LINKS = 0xffff }; ++/* ++ * We limit filesize to 4TB. This is arbitrary as the on-disk format supports ++ * more but because the file space is described by a linked list of extents, ++ * each of which can have at most 1GB, the creation and handling of extents ++ * gets unusably slow beyond certain point... ++ */ ++#define UDF_MAX_FILESIZE (1ULL << 42) + + /* These are the "meat" - everything else is stuffing */ + static int udf_fill_super(struct super_block *, void *, int); +@@ -2308,7 +2315,7 @@ static int udf_fill_super(struct super_b + ret = -ENOMEM; + goto error_out; + } +- sb->s_maxbytes = MAX_LFS_FILESIZE; ++ sb->s_maxbytes = UDF_MAX_FILESIZE; + sb->s_max_links = UDF_MAX_LINKS; + return 0; + diff --git a/queue-5.4/virtio_net-fix-napi_skb_cache_put-warning.patch b/queue-5.4/virtio_net-fix-napi_skb_cache_put-warning.patch new file mode 100644 index 00000000000..141b3b72d7f --- /dev/null +++ b/queue-5.4/virtio_net-fix-napi_skb_cache_put-warning.patch @@ -0,0 +1,88 @@ +From f8321fa75102246d7415a6af441872f6637c93ab Mon Sep 17 00:00:00 2001 +From: Breno Leitao +Date: Fri, 12 Jul 2024 04:53:25 -0700 +Subject: virtio_net: Fix napi_skb_cache_put warning + +From: Breno Leitao + +commit f8321fa75102246d7415a6af441872f6637c93ab upstream. + +After the commit bdacf3e34945 ("net: Use nested-BH locking for +napi_alloc_cache.") was merged, the following warning began to appear: + + WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 + + __warn+0x12f/0x340 + napi_skb_cache_put+0x82/0x4b0 + napi_skb_cache_put+0x82/0x4b0 + report_bug+0x165/0x370 + handle_bug+0x3d/0x80 + exc_invalid_op+0x1a/0x50 + asm_exc_invalid_op+0x1a/0x20 + __free_old_xmit+0x1c8/0x510 + napi_skb_cache_put+0x82/0x4b0 + __free_old_xmit+0x1c8/0x510 + __free_old_xmit+0x1c8/0x510 + __pfx___free_old_xmit+0x10/0x10 + +The issue arises because virtio is assuming it's running in NAPI context +even when it's not, such as in the netpoll case. + +To resolve this, modify virtnet_poll_tx() to only set NAPI when budget +is available. Same for virtnet_poll_cleantx(), which always assumed that +it was in a NAPI context. + +Fixes: df133f3f9625 ("virtio_net: bulk free tx skbs") +Suggested-by: Jakub Kicinski +Signed-off-by: Breno Leitao +Reviewed-by: Jakub Kicinski +Acked-by: Michael S. Tsirkin +Acked-by: Jason Wang +Reviewed-by: Heng Qi +Link: https://patch.msgid.link/20240712115325.54175-1-leitao@debian.org +Signed-off-by: Jakub Kicinski +[Shivani: Modified to apply on v4.19.y-v5.10.y] +Signed-off-by: Shivani Agarwal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/virtio_net.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/net/virtio_net.c ++++ b/drivers/net/virtio_net.c +@@ -1479,7 +1479,7 @@ static bool is_xdp_raw_buffer_queue(stru + return false; + } + +-static void virtnet_poll_cleantx(struct receive_queue *rq) ++static void virtnet_poll_cleantx(struct receive_queue *rq, int budget) + { + struct virtnet_info *vi = rq->vq->vdev->priv; + unsigned int index = vq2rxq(rq->vq); +@@ -1490,7 +1490,7 @@ static void virtnet_poll_cleantx(struct + return; + + if (__netif_tx_trylock(txq)) { +- free_old_xmit_skbs(sq, true); ++ free_old_xmit_skbs(sq, !!budget); + __netif_tx_unlock(txq); + } + +@@ -1507,7 +1507,7 @@ static int virtnet_poll(struct napi_stru + unsigned int received; + unsigned int xdp_xmit = 0; + +- virtnet_poll_cleantx(rq); ++ virtnet_poll_cleantx(rq, budget); + + received = virtnet_receive(rq, budget, &xdp_xmit); + +@@ -1580,7 +1580,7 @@ static int virtnet_poll_tx(struct napi_s + txq = netdev_get_tx_queue(vi->dev, index); + __netif_tx_lock(txq, raw_smp_processor_id()); + virtqueue_disable_cb(sq->vq); +- free_old_xmit_skbs(sq, true); ++ free_old_xmit_skbs(sq, !!budget); + + opaque = virtqueue_enable_cb_prepare(sq->vq); +