June 2024 - Linux-stable-mirror

[PATCH v7] af_packet: Handle outgoing VLAN packets without hardware offloading

by Chengen Du

The issue initially stems from libpcap. The ethertype will be overwritten as the VLAN TPID if the network interface lacks hardware VLAN offloading. In the outbound packet path, if hardware VLAN offloading is unavailable, the VLAN tag is inserted into the payload but then cleared from the sk_buff struct. Consequently, this can lead to a false negative when checking for the presence of a VLAN tag, causing the packet sniffing outcome to lack VLAN tag information (i.e., TCI-TPID). As a result, the packet capturing tool may be unable to parse packets as expected. The TCI-TPID is missing because the prb_fill_vlan_info() function does not modify the tp_vlan_tci/tp_vlan_tpid values, as the information is in the payload and not in the sk_buff struct. The skb_vlan_tag_present() function only checks vlan_all in the sk_buff struct. In cooked mode, the L2 header is stripped, preventing the packet capturing tool from determining the correct TCI-TPID value. Additionally, the protocol in SLL is incorrect, which means the packet capturing tool cannot parse the L3 header correctly. Link: https://github.com/the-tcpdump-group/libpcap/issues/1105 Link: https://lore.kernel.org/netdev/20240520070348.26725-1-chengen.du@canonical.… Fixes: 393e52e33c6c ("packet: deliver VLAN TCI to userspace") Cc: stable(a)vger.kernel.org Signed-off-by: Chengen Du <chengen.du(a)canonical.com> --- net/packet/af_packet.c | 93 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 91 insertions(+), 2 deletions(-) diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index ea3ebc160e25..41d6ebb38774 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -538,6 +538,69 @@ static void *packet_current_frame(struct packet_sock *po, return packet_lookup_frame(po, rb, rb->head, status); } +static u16 vlan_get_tci(struct sk_buff *skb, struct net_device *dev) +{ + struct vlan_hdr vhdr, *vh; + u8 *skb_orig_data = skb->data; + int skb_orig_len = skb->len; + unsigned int header_len; + + if (!dev) { + if (!skb->dev) + return 0; + dev = skb->dev; + } + + /* In the SOCK_DGRAM scenario, skb data starts at the network + * protocol, which is after the VLAN headers. The outer VLAN + * header is at the hard_header_len offset in non-variable + * length link layer headers. If it's a VLAN device, the + * min_header_len should be used to exclude the VLAN header + * size. + */ + if (dev->min_header_len == dev->hard_header_len) + header_len = dev->hard_header_len; + else if (is_vlan_dev(dev)) + header_len = dev->min_header_len; + else + return 0; + + skb_push(skb, skb->data - skb_mac_header(skb)); + vh = skb_header_pointer(skb, header_len, sizeof(vhdr), &vhdr); + if (skb_orig_data != skb->data) { + skb->data = skb_orig_data; + skb->len = skb_orig_len; + } + if (unlikely(!vh)) + return 0; + + return ntohs(vh->h_vlan_TCI); +} + +static __be16 vlan_get_protocol_dgram(struct sk_buff *skb) +{ + __be16 proto = skb->protocol; + + if (unlikely(eth_type_vlan(proto))) { + u8 *skb_orig_data = skb->data; + int skb_orig_len = skb->len; + + /* In the SOCK_DGRAM scenario, skb data starts at the network + * protocol, which is after the VLAN headers. The protocol must + * point to the network protocol to accurately reflect the real + * scenario. + */ + skb_push(skb, skb->data - skb_mac_header(skb)); + proto = __vlan_get_protocol(skb, proto, NULL); + if (skb_orig_data != skb->data) { + skb->data = skb_orig_data; + skb->len = skb_orig_len; + } + } + + return proto; +} + static void prb_del_retire_blk_timer(struct tpacket_kbdq_core *pkc) { del_timer_sync(&pkc->retire_blk_timer); @@ -1007,10 +1070,16 @@ static void prb_clear_rxhash(struct tpacket_kbdq_core *pkc, static void prb_fill_vlan_info(struct tpacket_kbdq_core *pkc, struct tpacket3_hdr *ppd) { + struct packet_sock *po = container_of(pkc, struct packet_sock, rx_ring.prb_bdqc); + if (skb_vlan_tag_present(pkc->skb)) { ppd->hv1.tp_vlan_tci = skb_vlan_tag_get(pkc->skb); ppd->hv1.tp_vlan_tpid = ntohs(pkc->skb->vlan_proto); ppd->tp_status = TP_STATUS_VLAN_VALID | TP_STATUS_VLAN_TPID_VALID; + } else if (unlikely(po->sk.sk_type == SOCK_DGRAM && eth_type_vlan(pkc->skb->protocol))) { + ppd->hv1.tp_vlan_tci = vlan_get_tci(pkc->skb, NULL); + ppd->hv1.tp_vlan_tpid = ntohs(pkc->skb->protocol); + ppd->tp_status = TP_STATUS_VLAN_VALID | TP_STATUS_VLAN_TPID_VALID; } else { ppd->hv1.tp_vlan_tci = 0; ppd->hv1.tp_vlan_tpid = 0; @@ -2428,6 +2497,10 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev, h.h2->tp_vlan_tci = skb_vlan_tag_get(skb); h.h2->tp_vlan_tpid = ntohs(skb->vlan_proto); status |= TP_STATUS_VLAN_VALID | TP_STATUS_VLAN_TPID_VALID; + } else if (unlikely(sk->sk_type == SOCK_DGRAM && eth_type_vlan(skb->protocol))) { + h.h2->tp_vlan_tci = vlan_get_tci(skb, NULL); + h.h2->tp_vlan_tpid = ntohs(skb->protocol); + status |= TP_STATUS_VLAN_VALID | TP_STATUS_VLAN_TPID_VALID; } else { h.h2->tp_vlan_tci = 0; h.h2->tp_vlan_tpid = 0; @@ -2457,7 +2530,8 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev, sll->sll_halen = dev_parse_header(skb, sll->sll_addr); sll->sll_family = AF_PACKET; sll->sll_hatype = dev->type; - sll->sll_protocol = skb->protocol; + sll->sll_protocol = (sk->sk_type == SOCK_DGRAM) ? + vlan_get_protocol_dgram(skb) : skb->protocol; sll->sll_pkttype = skb->pkt_type; if (unlikely(packet_sock_flag(po, PACKET_SOCK_ORIGDEV))) sll->sll_ifindex = orig_dev->ifindex; @@ -3482,7 +3556,8 @@ static int packet_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, /* Original length was stored in sockaddr_ll fields */ origlen = PACKET_SKB_CB(skb)->sa.origlen; sll->sll_family = AF_PACKET; - sll->sll_protocol = skb->protocol; + sll->sll_protocol = (sock->type == SOCK_DGRAM) ? + vlan_get_protocol_dgram(skb) : skb->protocol; } sock_recv_cmsgs(msg, sk, skb); @@ -3539,6 +3614,20 @@ static int packet_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, aux.tp_vlan_tci = skb_vlan_tag_get(skb); aux.tp_vlan_tpid = ntohs(skb->vlan_proto); aux.tp_status |= TP_STATUS_VLAN_VALID | TP_STATUS_VLAN_TPID_VALID; + } else if (unlikely(sock->type == SOCK_DGRAM && eth_type_vlan(skb->protocol))) { + struct sockaddr_ll *sll = &PACKET_SKB_CB(skb)->sa.ll; + struct net_device *dev; + + dev = dev_get_by_index(sock_net(sk), sll->sll_ifindex); + if (dev) { + aux.tp_vlan_tci = vlan_get_tci(skb, dev); + aux.tp_vlan_tpid = ntohs(skb->protocol); + aux.tp_status |= TP_STATUS_VLAN_VALID | TP_STATUS_VLAN_TPID_VALID; + dev_put(dev); + } else { + aux.tp_vlan_tci = 0; + aux.tp_vlan_tpid = 0; + } } else { aux.tp_vlan_tci = 0; aux.tp_vlan_tpid = 0; -- 2.43.0

1 year

2
1
0 0

[git:media_stage/master] media: ivsc: csi: add separate lock for v4l2 control handler

by Hans Verkuil

This is an automatic generated email to let you know that the following patch were queued: Subject: media: ivsc: csi: add separate lock for v4l2 control handler Author: Wentong Wu <wentong.wu(a)intel.com> Date: Fri Jun 7 21:25:46 2024 +0800 There're possibilities that privacy status change notification happens in the middle of the ongoing mei command which already takes the command lock, but v4l2_ctrl_s_ctrl() would also need the same lock prior to this patch, so this may results in circular locking problem. This patch adds one dedicated lock for v4l2 control handler to avoid described issue. Fixes: 29006e196a56 ("media: pci: intel: ivsc: Add CSI submodule") Cc: stable(a)vger.kernel.org # for 6.6 and later Reported-by: Hao Yao <hao.yao(a)intel.com> Signed-off-by: Wentong Wu <wentong.wu(a)intel.com> Tested-by: Jason Chen <jason.z.chen(a)intel.com> Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> drivers/media/pci/intel/ivsc/mei_csi.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- diff --git a/drivers/media/pci/intel/ivsc/mei_csi.c b/drivers/media/pci/intel/ivsc/mei_csi.c index f04a89584334..c6d8f72e4eec 100644 --- a/drivers/media/pci/intel/ivsc/mei_csi.c +++ b/drivers/media/pci/intel/ivsc/mei_csi.c @@ -126,6 +126,8 @@ struct mei_csi { struct v4l2_ctrl_handler ctrl_handler; struct v4l2_ctrl *freq_ctrl; struct v4l2_ctrl *privacy_ctrl; + /* lock for v4l2 controls */ + struct mutex ctrl_lock; unsigned int remote_pad; /* start streaming or not */ int streaming; @@ -559,11 +561,13 @@ static int mei_csi_init_controls(struct mei_csi *csi) u32 max; int ret; + mutex_init(&csi->ctrl_lock); + ret = v4l2_ctrl_handler_init(&csi->ctrl_handler, 2); if (ret) return ret; - csi->ctrl_handler.lock = &csi->lock; + csi->ctrl_handler.lock = &csi->ctrl_lock; max = ARRAY_SIZE(link_freq_menu_items) - 1; csi->freq_ctrl = v4l2_ctrl_new_int_menu(&csi->ctrl_handler, @@ -755,6 +759,7 @@ err_entity: err_ctrl_handler: v4l2_ctrl_handler_free(&csi->ctrl_handler); + mutex_destroy(&csi->ctrl_lock); v4l2_async_nf_unregister(&csi->notifier); v4l2_async_nf_cleanup(&csi->notifier); @@ -774,6 +779,7 @@ static void mei_csi_remove(struct mei_cl_device *cldev) v4l2_async_nf_unregister(&csi->notifier); v4l2_async_nf_cleanup(&csi->notifier); v4l2_ctrl_handler_free(&csi->ctrl_handler); + mutex_destroy(&csi->ctrl_lock); v4l2_async_unregister_subdev(&csi->subdev); v4l2_subdev_cleanup(&csi->subdev); media_entity_cleanup(&csi->subdev.entity);

1 year

1
0
0 0

[git:media_stage/master] media: ivsc: csi: don't count privacy on as error

by Hans Verkuil

This is an automatic generated email to let you know that the following patch were queued: Subject: media: ivsc: csi: don't count privacy on as error Author: Wentong Wu <wentong.wu(a)intel.com> Date: Fri Jun 7 21:25:45 2024 +0800 Prior to the ongoing command privacy is on, it would return -1 to indicate the current privacy status, and the ongoing command would be well executed by firmware as well, so this is not error. This patch changes its behavior to notify privacy on directly by V4L2 privacy control instead of reporting error. Fixes: 29006e196a56 ("media: pci: intel: ivsc: Add CSI submodule") Cc: stable(a)vger.kernel.org # for 6.6 and later Reported-by: Hao Yao <hao.yao(a)intel.com> Signed-off-by: Wentong Wu <wentong.wu(a)intel.com> Tested-by: Jason Chen <jason.z.chen(a)intel.com> Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> drivers/media/pci/intel/ivsc/mei_csi.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- diff --git a/drivers/media/pci/intel/ivsc/mei_csi.c b/drivers/media/pci/intel/ivsc/mei_csi.c index c6d8f72e4eec..16791a7f4f15 100644 --- a/drivers/media/pci/intel/ivsc/mei_csi.c +++ b/drivers/media/pci/intel/ivsc/mei_csi.c @@ -192,7 +192,11 @@ static int mei_csi_send(struct mei_csi *csi, u8 *buf, size_t len) /* command response status */ ret = csi->cmd_response.status; - if (ret) { + if (ret == -1) { + /* notify privacy on instead of reporting error */ + ret = 0; + v4l2_ctrl_s_ctrl(csi->privacy_ctrl, 1); + } else if (ret) { ret = -EINVAL; goto out; }

1 year

1
0
0 0

[git:media_stage/master] media: i2c: alvium: Move V4L2_CID_GAIN to V4L2_CID_ANALOG_GAIN

by Hans Verkuil

This is an automatic generated email to let you know that the following patch were queued: Subject: media: i2c: alvium: Move V4L2_CID_GAIN to V4L2_CID_ANALOG_GAIN Author: Tommaso Merciai <tomm.merciai(a)gmail.com> Date: Mon Jun 10 10:10:34 2024 +0200 Into alvium cameras REG_BCRM_GAIN_RW control the analog gain. Let's use the right V4L2_CID_ANALOGUE_GAIN ctrl. Fixes: 0a7af872915e ("media: i2c: Add support for alvium camera") Cc: stable(a)vger.kernel.org Signed-off-by: Tommaso Merciai <tomm.merciai(a)gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> drivers/media/i2c/alvium-csi2.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- diff --git a/drivers/media/i2c/alvium-csi2.c b/drivers/media/i2c/alvium-csi2.c index c27c6fcaede4..5ddfd3dcb188 100644 --- a/drivers/media/i2c/alvium-csi2.c +++ b/drivers/media/i2c/alvium-csi2.c @@ -1998,7 +1998,7 @@ static int alvium_g_volatile_ctrl(struct v4l2_ctrl *ctrl) int val; switch (ctrl->id) { - case V4L2_CID_GAIN: + case V4L2_CID_ANALOGUE_GAIN: val = alvium_get_gain(alvium); if (val < 0) return val; @@ -2030,7 +2030,7 @@ static int alvium_s_ctrl(struct v4l2_ctrl *ctrl) return 0; switch (ctrl->id) { - case V4L2_CID_GAIN: + case V4L2_CID_ANALOGUE_GAIN: ret = alvium_set_ctrl_gain(alvium, ctrl->val); break; case V4L2_CID_AUTOGAIN: @@ -2159,7 +2159,7 @@ static int alvium_ctrl_init(struct alvium_dev *alvium) if (alvium->avail_ft.gain) { ctrls->gain = v4l2_ctrl_new_std(hdl, ops, - V4L2_CID_GAIN, + V4L2_CID_ANALOGUE_GAIN, alvium->min_gain, alvium->max_gain, alvium->inc_gain,

1 year

1
0
0 0

[PATCH 6.6.y 0/2] Fix missing lib.sh for net/unicast_extensions.sh and net/pmtu.sh tests

by Po-Hsu Lin

Since upstream commit: * 0f4765d0 "selftests/net: convert unicast_extensions.sh to run it in unique namespace" * 378f082e "selftests/net: convert pmtu.sh to run it in unique namespace" The lib.sh from commit 25ae948b "selftests/net: add lib.sh" will be needed. Otherwise these test will complain about missing files and fail: $ sudo ./unicast_extensions.sh ./unicast_extensions.sh: line 31: lib.sh: No such file or directory ... $ sudo ./pmtu.sh ./pmtu.sh: line 201: lib.sh: No such file or directory ./pmtu.sh: line 941: cleanup_all_ns: command not found ... Another commit b6925b4e "selftests/net: add variable NS_LIST for lib.sh" is needed to add support for the cleanup_all_ns above. Hangbin Liu (2): selftests/net: add lib.sh selftests/net: add variable NS_LIST for lib.sh tools/testing/selftests/net/Makefile | 2 +- tools/testing/selftests/net/forwarding/lib.sh | 27 +------- tools/testing/selftests/net/lib.sh | 93 +++++++++++++++++++++++++++ 3 files changed, 95 insertions(+), 27 deletions(-) create mode 100644 tools/testing/selftests/net/lib.sh -- 2.7.4

1 year

2
3
0 0

+ ocfs2-fix-dio-failure-due-to-insufficient-transaction-credits.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: ocfs2: fix DIO failure due to insufficient transaction credits has been added to the -mm mm-hotfixes-unstable branch. Its filename is ocfs2-fix-dio-failure-due-to-insufficient-transaction-credits.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Jan Kara <jack(a)suse.cz> Subject: ocfs2: fix DIO failure due to insufficient transaction credits Date: Fri, 14 Jun 2024 16:52:43 +0200 The code in ocfs2_dio_end_io_write() estimates number of necessary transaction credits using ocfs2_calc_extend_credits(). This however does not take into account that the IO could be arbitrarily large and can contain arbitrary number of extents. Extent tree manipulations do often extend the current transaction but not in all of the cases. For example if we have only single block extents in the tree, ocfs2_mark_extent_written() will end up calling ocfs2_replace_extent_rec() all the time and we will never extend the current transaction and eventually exhaust all the transaction credits if the IO contains many single block extents. Make sure the transaction always has enough credits for one extent insert before each call of ocfs2_mark_extent_written(). Link: https://lkml.kernel.org/r/20240614145243.8837-1-jack@suse.cz Signed-off-by: Jan Kara <jack(a)suse.cz> Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: Heming Zhao <heming.zhao(a)suse.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Gang He <ghe(a)suse.com> Cc: Jun Piao <piaojun(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/ocfs2/aops.c | 5 +++++ fs/ocfs2/journal.c | 17 +++++++++++++++++ fs/ocfs2/journal.h | 2 ++ fs/ocfs2/ocfs2_trace.h | 2 ++ 4 files changed, 26 insertions(+) --- a/fs/ocfs2/aops.c~ocfs2-fix-dio-failure-due-to-insufficient-transaction-credits +++ a/fs/ocfs2/aops.c @@ -2366,6 +2366,11 @@ static int ocfs2_dio_end_io_write(struct } list_for_each_entry(ue, &dwc->dw_zero_list, ue_node) { + ret = ocfs2_assure_trans_credits(handle, credits); + if (ret < 0) { + mlog_errno(ret); + break; + } ret = ocfs2_mark_extent_written(inode, &et, handle, ue->ue_cpos, 1, ue->ue_phys, --- a/fs/ocfs2/journal.c~ocfs2-fix-dio-failure-due-to-insufficient-transaction-credits +++ a/fs/ocfs2/journal.c @@ -446,6 +446,23 @@ bail: } /* + * Make sure handle has at least 'nblocks' credits available. If it does not + * have that many credits available, we will try to extend the handle to have + * enough credits. If that fails, we will restart transaction to have enough + * credits. Similar notes regarding data consistency and locking implications + * as for ocfs2_extend_trans() apply here. + */ +int ocfs2_assure_trans_credits(handle_t *handle, int nblocks) +{ + int old_nblks = jbd2_handle_buffer_credits(handle); + + trace_ocfs2_assure_trans_credits(old_nblks); + if (old_nblks >= nblocks) + return 0; + return ocfs2_extend_trans(handle, nblocks - old_nblks); +} + +/* * If we have fewer than thresh credits, extend by OCFS2_MAX_TRANS_DATA. * If that fails, restart the transaction & regain write access for the * buffer head which is used for metadata modifications. --- a/fs/ocfs2/journal.h~ocfs2-fix-dio-failure-due-to-insufficient-transaction-credits +++ a/fs/ocfs2/journal.h @@ -243,6 +243,8 @@ handle_t *ocfs2_start_trans(struct int ocfs2_commit_trans(struct ocfs2_super *osb, handle_t *handle); int ocfs2_extend_trans(handle_t *handle, int nblocks); +int ocfs2_assure_trans_credits(handle_t *handle, + int nblocks); int ocfs2_allocate_extend_trans(handle_t *handle, int thresh); --- a/fs/ocfs2/ocfs2_trace.h~ocfs2-fix-dio-failure-due-to-insufficient-transaction-credits +++ a/fs/ocfs2/ocfs2_trace.h @@ -2577,6 +2577,8 @@ DEFINE_OCFS2_ULL_UINT_EVENT(ocfs2_commit DEFINE_OCFS2_INT_INT_EVENT(ocfs2_extend_trans); +DEFINE_OCFS2_INT_EVENT(ocfs2_assure_trans_credits); + DEFINE_OCFS2_INT_EVENT(ocfs2_extend_trans_restart); DEFINE_OCFS2_INT_INT_EVENT(ocfs2_allocate_extend_trans); _ Patches currently in -mm which might be from jack(a)suse.cz are ocfs2-fix-dio-failure-due-to-insufficient-transaction-credits.patch

1 year

1
0
0 0

[PATCH 1/2] docs: stable-kernel-rules: provide example of specifying target series

by Shung-Hsi Yu

Provide a concrete example of how to specify what stable series should be targeted for change inclusion. Looking around on the stable mailing list this seems like a common practice already, so let's mention that in the documentation as well (but worded so it is not interpreted as the only way to do so). Signed-off-by: Shung-Hsi Yu <shung-hsi.yu(a)suse.com> --- Documentation/process/stable-kernel-rules.rst | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index edf90bbe30f4..daa542988095 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -57,10 +57,13 @@ options for cases where a mainlined patch needs adjustments to apply in older series (for example due to API changes). When using option 2 or 3 you can ask for your change to be included in specific -stable series. When doing so, ensure the fix or an equivalent is applicable, -submitted, or already present in all newer stable trees still supported. This is -meant to prevent regressions that users might later encounter on updating, if -e.g. a fix merged for 5.19-rc1 would be backported to 5.10.y, but not to 5.15.y. +stable series, one way to do so is by specifying the target series in the +subject prefix (e.g. '[PATCH stable 5.15 5.10]' asks that the patch to be +included in both 5.10.y and 5.15.y). When doing so, ensure the fix or an +equivalent is applicable, submitted, or already present in all newer stable +trees still supported. This is meant to prevent regressions that users might +later encounter on updating, if e.g. a fix merged for 5.19-rc1 would be +backported to 5.10.y, but not to 5.15.y. .. _option_1: -- 2.45.1

1 year

3
5
0 0

+ kasan-fix-bad-call-to-unpoison_slab_object.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: kasan: fix bad call to unpoison_slab_object has been added to the -mm mm-hotfixes-unstable branch. Its filename is kasan-fix-bad-call-to-unpoison_slab_object.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Andrey Konovalov <andreyknvl(a)gmail.com> Subject: kasan: fix bad call to unpoison_slab_object Date: Fri, 14 Jun 2024 16:32:38 +0200 Commit 29d7355a9d05 ("kasan: save alloc stack traces for mempool") messed up one of the calls to unpoison_slab_object: the last two arguments are supposed to be GFP flags and whether to init the object memory. Fix the call. Without this fix, __kasan_mempool_unpoison_object provides the object's size as GFP flags to unpoison_slab_object, which can cause LOCKDEP reports (and probably other issues). Link: https://lkml.kernel.org/r/20240614143238.60323-1-andrey.konovalov@linux.dev Fixes: 29d7355a9d05 ("kasan: save alloc stack traces for mempool") Signed-off-by: Andrey Konovalov <andreyknvl(a)gmail.com> Reported-by: Brad Spengler <spender(a)grsecurity.net> Acked-by: Marco Elver <elver(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/kasan/common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/kasan/common.c~kasan-fix-bad-call-to-unpoison_slab_object +++ a/mm/kasan/common.c @@ -532,7 +532,7 @@ void __kasan_mempool_unpoison_object(voi return; /* Unpoison the object and save alloc info for non-kmalloc() allocations. */ - unpoison_slab_object(slab->slab_cache, ptr, size, flags); + unpoison_slab_object(slab->slab_cache, ptr, flags, false); /* Poison the redzone and save alloc info for kmalloc() allocations. */ if (is_kmalloc_cache(slab->slab_cache)) _ Patches currently in -mm which might be from andreyknvl(a)gmail.com are kasan-fix-bad-call-to-unpoison_slab_object.patch

1 year

1
0
0 0

FAILED: patch "[PATCH] io_uring: check for non-NULL file pointer in" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x 5fc16fa5f13b3c06fdb959ef262050bd810416a2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024061318-hypocrite-elude-31f3@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: 5fc16fa5f13b ("io_uring: check for non-NULL file pointer in io_file_can_poll()") 95041b93e90a ("io_uring: add io_file_can_poll() helper") 521223d7c229 ("io_uring/cancel: don't default to setting req->work.cancel_seq") 4bcb982cce74 ("io_uring: expand main struct io_kiocb flags to 64-bits") 595e52284d24 ("io_uring/poll: don't enable lazy wake for POLLEXCLUSIVE") 4de520f1fcef ("Merge tag 'io_uring-futex-2023-10-30' of git://git.kernel.dk/linux") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5fc16fa5f13b3c06fdb959ef262050bd810416a2 Mon Sep 17 00:00:00 2001 From: Jens Axboe <axboe(a)kernel.dk> Date: Sat, 1 Jun 2024 12:25:35 -0600 Subject: [PATCH] io_uring: check for non-NULL file pointer in io_file_can_poll() In earlier kernels, it was possible to trigger a NULL pointer dereference off the forced async preparation path, if no file had been assigned. The trace leading to that looks as follows: BUG: kernel NULL pointer dereference, address: 00000000000000b0 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 67 PID: 1633 Comm: buf-ring-invali Not tainted 6.8.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 2/2/2022 RIP: 0010:io_buffer_select+0xc3/0x210 Code: 00 00 48 39 d1 0f 82 ae 00 00 00 48 81 4b 48 00 00 01 00 48 89 73 70 0f b7 50 0c 66 89 53 42 85 ed 0f 85 d2 00 00 00 48 8b 13 <48> 8b 92 b0 00 00 00 48 83 7a 40 00 0f 84 21 01 00 00 4c 8b 20 5b RSP: 0018:ffffb7bec38c7d88 EFLAGS: 00010246 RAX: ffff97af2be61000 RBX: ffff97af234f1700 RCX: 0000000000000040 RDX: 0000000000000000 RSI: ffff97aecfb04820 RDI: ffff97af234f1700 RBP: 0000000000000000 R08: 0000000000200030 R09: 0000000000000020 R10: ffffb7bec38c7dc8 R11: 000000000000c000 R12: ffffb7bec38c7db8 R13: ffff97aecfb05800 R14: ffff97aecfb05800 R15: ffff97af2be5e000 FS: 00007f852f74b740(0000) GS:ffff97b1eeec0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000b0 CR3: 000000016deab005 CR4: 0000000000370ef0 Call Trace: <TASK> ? __die+0x1f/0x60 ? page_fault_oops+0x14d/0x420 ? do_user_addr_fault+0x61/0x6a0 ? exc_page_fault+0x6c/0x150 ? asm_exc_page_fault+0x22/0x30 ? io_buffer_select+0xc3/0x210 __io_import_iovec+0xb5/0x120 io_readv_prep_async+0x36/0x70 io_queue_sqe_fallback+0x20/0x260 io_submit_sqes+0x314/0x630 __do_sys_io_uring_enter+0x339/0xbc0 ? __do_sys_io_uring_register+0x11b/0xc50 ? vm_mmap_pgoff+0xce/0x160 do_syscall_64+0x5f/0x180 entry_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0x55e0a110a67e Code: ba cc 00 00 00 45 31 c0 44 0f b6 92 d0 00 00 00 31 d2 41 b9 08 00 00 00 41 83 e2 01 41 c1 e2 04 41 09 c2 b8 aa 01 00 00 0f 05 <c3> 90 89 30 eb a9 0f 1f 40 00 48 8b 42 20 8b 00 a8 06 75 af 85 f6 because the request is marked forced ASYNC and has a bad file fd, and hence takes the forced async prep path. Current kernels with the request async prep cleaned up can no longer hit this issue, but for ease of backporting, let's add this safety check in here too as it really doesn't hurt. For both cases, this will inevitably end with a CQE posted with -EBADF. Cc: stable(a)vger.kernel.org Fixes: a76c0b31eef5 ("io_uring: commit non-pollable provided mapped buffers upfront") Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/io_uring.h b/io_uring/io_uring.h index 624ca9076a50..726e6367af4d 100644 --- a/io_uring/io_uring.h +++ b/io_uring/io_uring.h @@ -433,7 +433,7 @@ static inline bool io_file_can_poll(struct io_kiocb *req) { if (req->flags & REQ_F_CAN_POLL) return true; - if (file_can_poll(req->file)) { + if (req->file && file_can_poll(req->file)) { req->flags |= REQ_F_CAN_POLL; return true; }

1 year

2
1
0 0

Re: [PATCH 6.9 000/157] 6.9.5-rc1 review

by Ronald Warsow

Hi Greg +++ Update +++ the below crash seems to only to happen with mesa-24.1.x mesa-24.0.9 is fine filled a bug report: https://bugzilla.redhat.com/show_bug.cgi?id=2292434 ==== Jun 13 18:49:22 obelix.fritz.box kernel: RIP: 0010:drm_suballoc_free+0x13/0x110 [drm_suballoc_helper] Jun 13 18:49:22 obelix.fritz.box kernel: Code: eb ce 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 48 85 ff 0f 84 e1 00 00 00 41 54 55 48 89 fd 53 48 89 f3 <4c> 8b 67 20 4c 89 e7 e8 61 53 bd e2 48 85 db 0f 84 9f 00 00 00 48 Jun 13 18:49:22 obelix.fritz.box kernel: RSP: 0018:ffff9caa851f7630 EFLAGS: 00010286 Jun 13 18:49:22 obelix.fritz.box kernel: RAX: fffffffffffffe00 RBX: 0000000000000000 RCX: 000000000000890b Jun 13 18:49:22 obelix.fritz.box kernel: RDX: 00000000000088fb RSI: 0000000000000000 RDI: fffffffffffffe00 Jun 13 18:49:22 obelix.fritz.box kernel: RBP: fffffffffffffe00 R08: 0000000000000000 R09: 0000000000000001 Jun 13 18:49:22 obelix.fritz.box kernel: R10: 0000000000000000 R11: 0000000000000180 R12: ffff8ebf913c1158 Jun 13 18:49:22 obelix.fritz.box kernel: R13: fffffffffffffe00 R14: ffff9caa851f78a8 R15: ffff8ebf913c0000 Jun 13 18:49:22 obelix.fritz.box kernel: FS: 00007fd4f4640b00(0000) GS:ffff8ec2cf980000(0000) knlGS:0000000000000000 Jun 13 18:49:22 obelix.fritz.box kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 13 18:49:22 obelix.fritz.box kernel: CR2: fffffffffffffe20 CR3: 0000000110bc4001 CR4: 0000000000770ef0 Jun 13 18:49:22 obelix.fritz.box kernel: PKRU: 55555554 Jun 13 18:49:22 obelix.fritz.box kernel: Call Trace: Jun 13 18:49:22 obelix.fritz.box kernel: <TASK> Jun 13 18:49:22 obelix.fritz.box kernel: ? __die_body.cold+0x19/0x2c Jun 13 18:49:22 obelix.fritz.box kernel: ? page_fault_oops+0x155/0x280 Jun 13 18:49:22 obelix.fritz.box kernel: ? search_module_extables+0x10/0x50 Jun 13 18:49:22 obelix.fritz.box kernel: ? search_bpf_extables+0x56/0x80 Jun 13 18:49:22 obelix.fritz.box kernel: ? exc_page_fault+0x7a/0x80 Jun 13 18:49:22 obelix.fritz.box kernel: ? asm_exc_page_fault+0x22/0x30 Jun 13 18:49:22 obelix.fritz.box kernel: ? drm_suballoc_free+0x13/0x110 [drm_suballoc_helper] Jun 13 18:49:22 obelix.fritz.box kernel: xe_migrate_update_pgtables+0x692/0x9b0 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: ? kmalloc_trace+0x11f/0x2d0 Jun 13 18:49:22 obelix.fritz.box kernel: __xe_pt_bind_vma+0x492/0xbe0 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: xe_vm_bind_vma+0xa6/0x2e0 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: xe_vm_bind+0xf3/0x200 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: __xe_vma_op_execute+0x278/0x490 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: xe_vm_bind_ioctl+0x1ce0/0x1f20 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: drm_ioctl_kernel+0xa7/0x100 [drm] Jun 13 18:49:22 obelix.fritz.box kernel: drm_ioctl+0x312/0x5c0 [drm] Jun 13 18:49:22 obelix.fritz.box kernel: ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: __x64_sys_ioctl+0x40d/0xb70 Jun 13 18:49:22 obelix.fritz.box kernel: do_syscall_64+0x7a/0x160 Jun 13 18:49:22 obelix.fritz.box kernel: ? __x64_sys_ioctl+0x13e/0xb70 Jun 13 18:49:22 obelix.fritz.box kernel: ? __count_memcg_events+0x43/0xb0 Jun 13 18:49:22 obelix.fritz.box kernel: ? handle_mm_fault+0x1f9/0x300 Jun 13 18:49:22 obelix.fritz.box kernel: ? syscall_exit_to_user_mode+0x68/0x1e0 Jun 13 18:49:22 obelix.fritz.box kernel: ? do_syscall_64+0x86/0x160 Jun 13 18:49:22 obelix.fritz.box kernel: ? clear_bhb_loop+0x45/0xa0 Jun 13 18:49:22 obelix.fritz.box kernel: ? clear_bhb_loop+0x45/0xa0 Jun 13 18:49:22 obelix.fritz.box kernel: ? clear_bhb_loop+0x45/0xa0 Jun 13 18:49:22 obelix.fritz.box kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e Jun 13 18:49:22 obelix.fritz.box kernel: RIP: 0033:0x7fd4f4d23d2d Jun 13 18:49:22 obelix.fritz.box kernel: Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00 Jun 13 18:49:22 obelix.fritz.box kernel: RSP: 002b:00007fff94738650 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 Jun 13 18:49:22 obelix.fritz.box kernel: RAX: ffffffffffffffda RBX: 00007fff94738710 RCX: 00007fd4f4d23d2d Jun 13 18:49:22 obelix.fritz.box kernel: RDX: 00007fff94738710 RSI: 0000000040886445 RDI: 0000000000000010 Jun 13 18:49:22 obelix.fritz.box kernel: RBP: 00007fff947386a0 R08: 0000000000001000 R09: 0000000000000000 Jun 13 18:49:22 obelix.fritz.box kernel: R10: 0000555a7a0fded0 R11: 0000000000000246 R12: 0000000000000010 Jun 13 18:49:22 obelix.fritz.box kernel: R13: 0000000000000000 R14: 0000555a78671160 R15: 0000555a7a234fa0 Jun 13 18:49:22 obelix.fritz.box kernel: </TASK> Jun 13 18:49:22 obelix.fritz.box kernel: Modules linked in: vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) rfcomm nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables bnep iwlmvm mac80211 libarc4 snd_hda_codec_hdmi intel_rapl_common kvm_intel iwlwifi snd_hda_codec_realtek kvm btusb snd_hda_codec_generic btintel snd_hda_scodec_component bluetooth snd_hda_intel cfg80211 snd_intel_dspcfg snd_hda_codec snd_hda_core mei_hdcp mei_pxp rfkill nfnetlink xe drm_ttm_helper ttm agpgart i2c_algo_bit gpu_sched drm_buddy drm_suballoc_helper drm_gpuvm drm_exec drm_display_helper drm_kms_helper drm Jun 13 18:49:22 obelix.fritz.box kernel: CR2: fffffffffffffe20 Jun 13 18:49:22 obelix.fritz.box kernel: ---[ end trace 0000000000000000 ]--- Jun 13 18:49:22 obelix.fritz.box kernel: RIP: 0010:drm_suballoc_free+0x13/0x110 [drm_suballoc_helper] Jun 13 18:49:22 obelix.fritz.box kernel: Code: eb ce 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 48 85 ff 0f 84 e1 00 00 00 41 54 55 48 89 fd 53 48 89 f3 <4c> 8b 67 20 4c 89 e7 e8 61 53 bd e2 48 85 db 0f 84 9f 00 00 00 48 Jun 13 18:49:22 obelix.fritz.box kernel: RSP: 0018:ffff9caa851f7630 EFLAGS: 00010286 Jun 13 18:49:22 obelix.fritz.box kernel: RAX: fffffffffffffe00 RBX: 0000000000000000 RCX: 000000000000890b Jun 13 18:49:22 obelix.fritz.box kernel: RDX: 00000000000088fb RSI: 0000000000000000 RDI: fffffffffffffe00 Jun 13 18:49:22 obelix.fritz.box kernel: RBP: fffffffffffffe00 R08: 0000000000000000 R09: 0000000000000001 Jun 13 18:49:22 obelix.fritz.box kernel: R10: 0000000000000000 R11: 0000000000000180 R12: ffff8ebf913c1158 Jun 13 18:49:22 obelix.fritz.box kernel: R13: fffffffffffffe00 R14: ffff9caa851f78a8 R15: ffff8ebf913c0000 Jun 13 18:49:22 obelix.fritz.box kernel: FS: 00007fd4f4640b00(0000) GS:ffff8ec2cf980000(0000) knlGS:0000000000000000 Jun 13 18:49:22 obelix.fritz.box kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 13 18:49:22 obelix.fritz.box kernel: CR2: fffffffffffffe20 CR3: 0000000110bc4001 CR4: 0000000000770ef0 Jun 13 18:49:22 obelix.fritz.box kernel: PKRU: 55555554 Jun 13 18:49:22 obelix.fritz.box kernel: note: Xorg[3657] exited with irqs disabled

1 year

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2024