- Linux-stable-mirror - lists.linaro.org

[PATCH] LoongArch: Fix build errors for CONFIG_RANDSTRUCT

by Huacai Chen

When CONFIG_RANDSTRUCT enabled, members of task_struct are randomized. There is a chance that TASK_STACK_CANARY be out of 12bit immediate's range and causes build errors. TASK_STACK_CANARY is naturally aligned, so fix it by replacing ld.d/st.d with ldptr.d/stptr.d which have 14bit immediates. Cc: stable(a)vger.kernel.org Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202511240656.0NaPcJs1-lkp@intel.com/ Suggested-by: Rui Wang <wangrui(a)loongson.cn> Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> --- arch/loongarch/kernel/switch.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/loongarch/kernel/switch.S b/arch/loongarch/kernel/switch.S index 9c23cb7e432f..3007e909e0d8 100644 --- a/arch/loongarch/kernel/switch.S +++ b/arch/loongarch/kernel/switch.S @@ -25,8 +25,8 @@ SYM_FUNC_START(__switch_to) stptr.d a4, a0, THREAD_SCHED_CFA #if defined(CONFIG_STACKPROTECTOR) && !defined(CONFIG_SMP) la t7, __stack_chk_guard - LONG_L t8, a1, TASK_STACK_CANARY - LONG_S t8, t7, 0 + ldptr.d t8, a1, TASK_STACK_CANARY + stptr.d t8, t7, 0 #endif move tp, a2 cpu_restore_nonscratch a1 -- 2.47.3

14 hours, 17 minutes

3
2
0 0

[PATCH 1/2] Revert "block: Move checking GENHD_FL_NO_PART to bdev_add_partition()"

by Gulam Mohamed

This reverts commit 7777f47f2ea64efd1016262e7b59fab34adfb869. The commit 1a721de8489f ("block: don't add or resize partition on the disk with GENHD_FL_NO_PART") and the commit 7777f47f2ea6 ("block: Move checking GENHD_FL_NO_PART to bdev_add_partition()") used the flag GENHD_FL_NO_PART to prevent the add or resize of partitions in 5.15 stable kernels.But in these 5.15 kernels, this is giving an issue with the following error where the loop driver wants to create a partition when the partscan is disabled on the loop device: dd if=/dev/zero of=loopDisk.dsk bs=1M count=1 seek=10240; losetup -f loopDisk.dsk;parted -s /dev/loop0 -- mklabel gpt mkpart primary 2048s 4096s 1+0 records in 1+0 records out 1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0016293 s, 644 MB/s "" Error: Partition(s) 1 on /dev/loop0 have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes. "" If the partition scan is not enabled on the loop device, this flag GENHD_FL_NO_PART is getting set and when partition creation is tried, it returns an error EINVAL thereby preventing the creation of partitions. So, there is no such distinction between disabling of partition scan and partition creation. Later in 6.xxx kernels, the commit b9684a71fca7 ("block, loop: support partitions without scanning") a new flag GD_SUPPRESS_PART_SCAN was introduced that just disables the partition scan and uses GENHD_FL_NO_PART only to prevent creating partition scan. So, the partition creationg can proceed with even if partition scan is disabled. As the commit b9684a71fca7 ("block, loop: support partitions without scanning") is not available in 5.15 stable kernel, and since there is no distinction between disabling of "partition scan" and "partition creation", we need to revert the commits 1a721de8489f and 7777f47f2ea6 from 5.15 stable kernel to allow partition creation when partscan is disabled. Cc: stable(a)vger.kernel.org Signed-off-by: Gulam Mohamed <gulam.mohamed(a)oracle.com> --- block/ioctl.c | 2 ++ block/partitions/core.c | 5 ----- 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/block/ioctl.c b/block/ioctl.c index a260e39e56a4..d25b84441237 100644 --- a/block/ioctl.c +++ b/block/ioctl.c @@ -20,6 +20,8 @@ static int blkpg_do_ioctl(struct block_device *bdev, struct blkpg_partition p; sector_t start, length; + if (disk->flags & GENHD_FL_NO_PART) + return -EINVAL; if (!capable(CAP_SYS_ADMIN)) return -EACCES; if (copy_from_user(&p, upart, sizeof(struct blkpg_partition))) diff --git a/block/partitions/core.c b/block/partitions/core.c index 0d1fe2b42b85..7b5750db7eaf 100644 --- a/block/partitions/core.c +++ b/block/partitions/core.c @@ -463,11 +463,6 @@ int bdev_add_partition(struct gendisk *disk, int partno, sector_t start, goto out; } - if (disk->flags & GENHD_FL_NO_PART) { - ret = -EINVAL; - goto out; - } - if (partition_overlaps(disk, start, length, -1)) { ret = -EBUSY; goto out; -- 2.47.3

14 hours, 25 minutes

2
6
0 0

[PATCH 5.15.y 1/2] Revert "block: Move checking GENHD_FL_NO_PART to bdev_add_partition()"

by Gulam Mohamed

This reverts commit 7777f47f2ea64efd1016262e7b59fab34adfb869. The commit 1a721de8489f ("block: don't add or resize partition on the disk with GENHD_FL_NO_PART") and the commit 7777f47f2ea6 ("block: Move checking GENHD_FL_NO_PART to bdev_add_partition()") used the flag GENHD_FL_NO_PART to prevent the add or resize of partitions in 5.15 stable kernels.But in these 5.15 kernels, this is giving an issue with the following error where the loop driver wants to create a partition when the partscan is disabled on the loop device: dd if=/dev/zero of=loopDisk.dsk bs=1M count=1 seek=10240; losetup -f loopDisk.dsk;parted -s /dev/loop0 -- mklabel gpt mkpart primary 2048s 4096s 1+0 records in 1+0 records out 1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0016293 s, 644 MB/s "" Error: Partition(s) 1 on /dev/loop0 have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes. "" If the partition scan is not enabled on the loop device, this flag GENHD_FL_NO_PART is getting set and when partition creation is tried, it returns an error EINVAL thereby preventing the creation of partitions. So, there is no such distinction between disabling of partition scan and partition creation. Later in 6.xxx kernels, the commit b9684a71fca7 ("block, loop: support partitions without scanning") a new flag GD_SUPPRESS_PART_SCAN was introduced that just disables the partition scan and uses GENHD_FL_NO_PART only to prevent creating partition scan. So, the partition creationg can proceed with even if partition scan is disabled. As the commit b9684a71fca7 ("block, loop: support partitions without scanning") is not available in 5.15 stable kernel, and since there is no distinction between disabling of "partition scan" and "partition creation", we need to revert the commits 1a721de8489f and 7777f47f2ea6 from 5.15 stable kernel to allow partition creation when partscan is disabled. Cc: stable(a)vger.kernel.org Signed-off-by: Gulam Mohamed <gulam.mohamed(a)oracle.com> --- block/ioctl.c | 2 ++ block/partitions/core.c | 5 ----- 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/block/ioctl.c b/block/ioctl.c index a260e39e56a4..d25b84441237 100644 --- a/block/ioctl.c +++ b/block/ioctl.c @@ -20,6 +20,8 @@ static int blkpg_do_ioctl(struct block_device *bdev, struct blkpg_partition p; sector_t start, length; + if (disk->flags & GENHD_FL_NO_PART) + return -EINVAL; if (!capable(CAP_SYS_ADMIN)) return -EACCES; if (copy_from_user(&p, upart, sizeof(struct blkpg_partition))) diff --git a/block/partitions/core.c b/block/partitions/core.c index 0d1fe2b42b85..7b5750db7eaf 100644 --- a/block/partitions/core.c +++ b/block/partitions/core.c @@ -463,11 +463,6 @@ int bdev_add_partition(struct gendisk *disk, int partno, sector_t start, goto out; } - if (disk->flags & GENHD_FL_NO_PART) { - ret = -EINVAL; - goto out; - } - if (partition_overlaps(disk, start, length, -1)) { ret = -EBUSY; goto out; -- 2.47.3

14 hours, 27 minutes

1
0
0 0

[PATCH net V2] vhost: rewind next_avail_head while discarding descriptors

by Jason Wang

When discarding descriptors with IN_ORDER, we should rewind next_avail_head otherwise it would run out of sync with last_avail_idx. This would cause driver to report "id X is not a head". Fixing this by returning the number of descriptors that is used for each buffer via vhost_get_vq_desc_n() so caller can use the value while discarding descriptors. Fixes: 67a873df0c41 ("vhost: basic in order support") Cc: stable(a)vger.kernel.org Signed-off-by: Jason Wang <jasowang(a)redhat.com> --- Changes since V1: - Add the function document - Tweak the variable name --- drivers/vhost/net.c | 53 ++++++++++++++++++------------ drivers/vhost/vhost.c | 76 +++++++++++++++++++++++++++++++++++-------- drivers/vhost/vhost.h | 10 +++++- 3 files changed, 103 insertions(+), 36 deletions(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index 35ded4330431..8f7f50acb6d6 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -592,14 +592,15 @@ static void vhost_net_busy_poll(struct vhost_net *net, static int vhost_net_tx_get_vq_desc(struct vhost_net *net, struct vhost_net_virtqueue *tnvq, unsigned int *out_num, unsigned int *in_num, - struct msghdr *msghdr, bool *busyloop_intr) + struct msghdr *msghdr, bool *busyloop_intr, + unsigned int *ndesc) { struct vhost_net_virtqueue *rnvq = &net->vqs[VHOST_NET_VQ_RX]; struct vhost_virtqueue *rvq = &rnvq->vq; struct vhost_virtqueue *tvq = &tnvq->vq; - int r = vhost_get_vq_desc(tvq, tvq->iov, ARRAY_SIZE(tvq->iov), - out_num, in_num, NULL, NULL); + int r = vhost_get_vq_desc_n(tvq, tvq->iov, ARRAY_SIZE(tvq->iov), + out_num, in_num, NULL, NULL, ndesc); if (r == tvq->num && tvq->busyloop_timeout) { /* Flush batched packets first */ @@ -610,8 +611,8 @@ static int vhost_net_tx_get_vq_desc(struct vhost_net *net, vhost_net_busy_poll(net, rvq, tvq, busyloop_intr, false); - r = vhost_get_vq_desc(tvq, tvq->iov, ARRAY_SIZE(tvq->iov), - out_num, in_num, NULL, NULL); + r = vhost_get_vq_desc_n(tvq, tvq->iov, ARRAY_SIZE(tvq->iov), + out_num, in_num, NULL, NULL, ndesc); } return r; @@ -642,12 +643,14 @@ static int get_tx_bufs(struct vhost_net *net, struct vhost_net_virtqueue *nvq, struct msghdr *msg, unsigned int *out, unsigned int *in, - size_t *len, bool *busyloop_intr) + size_t *len, bool *busyloop_intr, + unsigned int *ndesc) { struct vhost_virtqueue *vq = &nvq->vq; int ret; - ret = vhost_net_tx_get_vq_desc(net, nvq, out, in, msg, busyloop_intr); + ret = vhost_net_tx_get_vq_desc(net, nvq, out, in, msg, + busyloop_intr, ndesc); if (ret < 0 || ret == vq->num) return ret; @@ -766,6 +769,7 @@ static void handle_tx_copy(struct vhost_net *net, struct socket *sock) int sent_pkts = 0; bool sock_can_batch = (sock->sk->sk_sndbuf == INT_MAX); bool in_order = vhost_has_feature(vq, VIRTIO_F_IN_ORDER); + unsigned int ndesc = 0; do { bool busyloop_intr = false; @@ -774,7 +778,7 @@ static void handle_tx_copy(struct vhost_net *net, struct socket *sock) vhost_tx_batch(net, nvq, sock, &msg); head = get_tx_bufs(net, nvq, &msg, &out, &in, &len, - &busyloop_intr); + &busyloop_intr, &ndesc); /* On error, stop handling until the next kick. */ if (unlikely(head < 0)) break; @@ -806,7 +810,7 @@ static void handle_tx_copy(struct vhost_net *net, struct socket *sock) goto done; } else if (unlikely(err != -ENOSPC)) { vhost_tx_batch(net, nvq, sock, &msg); - vhost_discard_vq_desc(vq, 1); + vhost_discard_vq_desc(vq, 1, ndesc); vhost_net_enable_vq(net, vq); break; } @@ -829,7 +833,7 @@ static void handle_tx_copy(struct vhost_net *net, struct socket *sock) err = sock->ops->sendmsg(sock, &msg, len); if (unlikely(err < 0)) { if (err == -EAGAIN || err == -ENOMEM || err == -ENOBUFS) { - vhost_discard_vq_desc(vq, 1); + vhost_discard_vq_desc(vq, 1, ndesc); vhost_net_enable_vq(net, vq); break; } @@ -868,6 +872,7 @@ static void handle_tx_zerocopy(struct vhost_net *net, struct socket *sock) int err; struct vhost_net_ubuf_ref *ubufs; struct ubuf_info_msgzc *ubuf; + unsigned int ndesc = 0; bool zcopy_used; int sent_pkts = 0; @@ -879,7 +884,7 @@ static void handle_tx_zerocopy(struct vhost_net *net, struct socket *sock) busyloop_intr = false; head = get_tx_bufs(net, nvq, &msg, &out, &in, &len, - &busyloop_intr); + &busyloop_intr, &ndesc); /* On error, stop handling until the next kick. */ if (unlikely(head < 0)) break; @@ -941,7 +946,7 @@ static void handle_tx_zerocopy(struct vhost_net *net, struct socket *sock) vq->heads[ubuf->desc].len = VHOST_DMA_DONE_LEN; } if (retry) { - vhost_discard_vq_desc(vq, 1); + vhost_discard_vq_desc(vq, 1, ndesc); vhost_net_enable_vq(net, vq); break; } @@ -1045,11 +1050,12 @@ static int get_rx_bufs(struct vhost_net_virtqueue *nvq, unsigned *iovcount, struct vhost_log *log, unsigned *log_num, - unsigned int quota) + unsigned int quota, + unsigned int *ndesc) { struct vhost_virtqueue *vq = &nvq->vq; bool in_order = vhost_has_feature(vq, VIRTIO_F_IN_ORDER); - unsigned int out, in; + unsigned int out, in, desc_num, n = 0; int seg = 0; int headcount = 0; unsigned d; @@ -1064,9 +1070,9 @@ static int get_rx_bufs(struct vhost_net_virtqueue *nvq, r = -ENOBUFS; goto err; } - r = vhost_get_vq_desc(vq, vq->iov + seg, - ARRAY_SIZE(vq->iov) - seg, &out, - &in, log, log_num); + r = vhost_get_vq_desc_n(vq, vq->iov + seg, + ARRAY_SIZE(vq->iov) - seg, &out, + &in, log, log_num, &desc_num); if (unlikely(r < 0)) goto err; @@ -1093,6 +1099,7 @@ static int get_rx_bufs(struct vhost_net_virtqueue *nvq, ++headcount; datalen -= len; seg += in; + n += desc_num; } *iovcount = seg; @@ -1113,9 +1120,11 @@ static int get_rx_bufs(struct vhost_net_virtqueue *nvq, nheads[0] = headcount; } + *ndesc = n; + return headcount; err: - vhost_discard_vq_desc(vq, headcount); + vhost_discard_vq_desc(vq, headcount, n); return r; } @@ -1151,6 +1160,7 @@ static void handle_rx(struct vhost_net *net) struct iov_iter fixup; __virtio16 num_buffers; int recv_pkts = 0; + unsigned int ndesc; mutex_lock_nested(&vq->mutex, VHOST_NET_VQ_RX); sock = vhost_vq_get_backend(vq); @@ -1182,7 +1192,8 @@ static void handle_rx(struct vhost_net *net) headcount = get_rx_bufs(nvq, vq->heads + count, vq->nheads + count, vhost_len, &in, vq_log, &log, - likely(mergeable) ? UIO_MAXIOV : 1); + likely(mergeable) ? UIO_MAXIOV : 1, + &ndesc); /* On error, stop handling until the next kick. */ if (unlikely(headcount < 0)) goto out; @@ -1228,7 +1239,7 @@ static void handle_rx(struct vhost_net *net) if (unlikely(err != sock_len)) { pr_debug("Discarded rx packet: " " len %d, expected %zd\n", err, sock_len); - vhost_discard_vq_desc(vq, headcount); + vhost_discard_vq_desc(vq, headcount, ndesc); continue; } /* Supply virtio_net_hdr if VHOST_NET_F_VIRTIO_NET_HDR */ @@ -1252,7 +1263,7 @@ static void handle_rx(struct vhost_net *net) copy_to_iter(&num_buffers, sizeof num_buffers, &fixup) != sizeof num_buffers) { vq_err(vq, "Failed num_buffers write"); - vhost_discard_vq_desc(vq, headcount); + vhost_discard_vq_desc(vq, headcount, ndesc); goto out; } nvq->done_idx += headcount; diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index 8570fdf2e14a..a78226b37739 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -2792,18 +2792,34 @@ static int get_indirect(struct vhost_virtqueue *vq, return 0; } -/* This looks in the virtqueue and for the first available buffer, and converts - * it to an iovec for convenient access. Since descriptors consist of some - * number of output then some number of input descriptors, it's actually two - * iovecs, but we pack them into one and note how many of each there were. +/** + * vhost_get_vq_desc_n - Fetch the next available descriptor chain and build iovecs + * @vq: target virtqueue + * @iov: array that receives the scatter/gather segments + * @iov_size: capacity of @iov in elements + * @out_num: the number of output segments + * @in_num: the number of input segments + * @log: optional array to record addr/len for each writable segment; NULL if unused + * @log_num: optional output; number of entries written to @log when provided + * @ndesc: optional output; number of descriptors consumed from the available ring + * (useful for rollback via vhost_discard_vq_desc) * - * This function returns the descriptor number found, or vq->num (which is - * never a valid descriptor number) if none was found. A negative code is - * returned on error. */ -int vhost_get_vq_desc(struct vhost_virtqueue *vq, - struct iovec iov[], unsigned int iov_size, - unsigned int *out_num, unsigned int *in_num, - struct vhost_log *log, unsigned int *log_num) + * Extracts one available descriptor chain from @vq and translates guest addresses + * into host iovecs. + * + * On success, advances @vq->last_avail_idx by 1 and @vq->next_avail_head by the + * number of descriptors consumed (also stored via @ndesc when non-NULL). + * + * Return: + * - head index in [0, @vq->num) on success; + * - @vq->num if no descriptor is currently available; + * - negative errno on failure + */ +int vhost_get_vq_desc_n(struct vhost_virtqueue *vq, + struct iovec iov[], unsigned int iov_size, + unsigned int *out_num, unsigned int *in_num, + struct vhost_log *log, unsigned int *log_num, + unsigned int *ndesc) { bool in_order = vhost_has_feature(vq, VIRTIO_F_IN_ORDER); struct vring_desc desc; @@ -2921,17 +2937,49 @@ int vhost_get_vq_desc(struct vhost_virtqueue *vq, vq->last_avail_idx++; vq->next_avail_head += c; + if (ndesc) + *ndesc = c; + /* Assume notifications from guest are disabled at this point, * if they aren't we would need to update avail_event index. */ BUG_ON(!(vq->used_flags & VRING_USED_F_NO_NOTIFY)); return head; } +EXPORT_SYMBOL_GPL(vhost_get_vq_desc_n); + +/* This looks in the virtqueue and for the first available buffer, and converts + * it to an iovec for convenient access. Since descriptors consist of some + * number of output then some number of input descriptors, it's actually two + * iovecs, but we pack them into one and note how many of each there were. + * + * This function returns the descriptor number found, or vq->num (which is + * never a valid descriptor number) if none was found. A negative code is + * returned on error. + */ +int vhost_get_vq_desc(struct vhost_virtqueue *vq, + struct iovec iov[], unsigned int iov_size, + unsigned int *out_num, unsigned int *in_num, + struct vhost_log *log, unsigned int *log_num) +{ + return vhost_get_vq_desc_n(vq, iov, iov_size, out_num, in_num, + log, log_num, NULL); +} EXPORT_SYMBOL_GPL(vhost_get_vq_desc); -/* Reverse the effect of vhost_get_vq_desc. Useful for error handling. */ -void vhost_discard_vq_desc(struct vhost_virtqueue *vq, int n) +/** + * vhost_discard_vq_desc - Reverse the effect of vhost_get_vq_desc_n() + * @vq: target virtqueue + * @nbufs: number of buffers to roll back + * @ndesc: number of descriptors to roll back + * + * Rewinds the internal consumer cursors after a failed attempt to use buffers + * returned by vhost_get_vq_desc_n(). + */ +void vhost_discard_vq_desc(struct vhost_virtqueue *vq, int nbufs, + unsigned int ndesc) { - vq->last_avail_idx -= n; + vq->next_avail_head -= ndesc; + vq->last_avail_idx -= nbufs; } EXPORT_SYMBOL_GPL(vhost_discard_vq_desc); diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h index 621a6d9a8791..b49f08e4a1b4 100644 --- a/drivers/vhost/vhost.h +++ b/drivers/vhost/vhost.h @@ -230,7 +230,15 @@ int vhost_get_vq_desc(struct vhost_virtqueue *, struct iovec iov[], unsigned int iov_size, unsigned int *out_num, unsigned int *in_num, struct vhost_log *log, unsigned int *log_num); -void vhost_discard_vq_desc(struct vhost_virtqueue *, int n); + +int vhost_get_vq_desc_n(struct vhost_virtqueue *vq, + struct iovec iov[], unsigned int iov_size, + unsigned int *out_num, unsigned int *in_num, + struct vhost_log *log, unsigned int *log_num, + unsigned int *ndesc); + +void vhost_discard_vq_desc(struct vhost_virtqueue *, int nbuf, + unsigned int ndesc); bool vhost_vq_work_queue(struct vhost_virtqueue *vq, struct vhost_work *work); bool vhost_vq_has_work(struct vhost_virtqueue *vq); -- 2.31.1

14 hours, 59 minutes

3
4
0 0

[PATCH v4] mailbox: Prevent out-of-bounds access in fw_mbox_index_xlate()

by Joonwon Kang

Although it is guided that `#mbox-cells` must be at least 1, there are many instances of `#mbox-cells = <0>;` in the device tree. If that is the case and the corresponding mailbox controller does not provide `fw_xlate` and of_xlate` function pointers, `fw_mbox_index_xlate()` will be used by default and out-of-bounds accesses could occur due to lack of bounds check in that function. Cc: stable(a)vger.kernel.org Signed-off-by: Joonwon Kang <joonwonkang(a)google.com> --- V3 -> V4: Prevented access to sp->args[0] if sp->nargs < 1 and rebased on the linux-next tree. For CVE review, below is a problematic control flow when `#mbox-cells = <0>;`: ``` static struct mbox_chan * fw_mbox_index_xlate(struct mbox_controller *mbox, const struct fwnode_reference_args *sp) { int ind = sp->args[0]; // (4) if (ind >= mbox->num_chans) // (5) return ERR_PTR(-EINVAL); return &mbox->chans[ind]; // (6) } struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index) { ... struct fwnode_reference_args fwspec; // (1) ... ret = fwnode_property_get_reference_args(fwnode, "mboxes", // (2) "#mbox-cells", 0, index, &fwspec); ... scoped_guard(mutex, &con_mutex) { ... list_for_each_entry(mbox, &mbox_cons, node) { if (device_match_fwnode(mbox->dev, fwspec.fwnode)) { if (mbox->fw_xlate) { chan = mbox->fw_xlate(mbox, &fwspec); // (3) if (!IS_ERR(chan)) break; } ... } } ... ret = __mbox_bind_client(chan, cl); // (7) ... } ... } static int __mbox_bind_client(struct mbox_chan *chan, struct mbox_client *cl) { if (chan->cl || ...) { // (8) } ``` (1) `fwspec.args[]` is filled with arbitrary leftover values in the stack. Let's say that `fwspec.args[0] == 0xffffffff`. (2) Since `#mbox-cells = <0>;`, `fwspec.nargs` is assigned 0 and `fwspec.args[]` are untouched. (3) Since the controller has not provided `fw_xlate` and `of_xlate`, `fw_mbox_index_xlate()` is used instead. (4) `idx` is assigned -1 due to the value of `fwspec.args[0]`. (5) Since `mbox->num_chans >= 0` and `idx == -1`, this condition does not filter out this case. (6) Out-of-bounds address is returned. Depending on what was left in `fwspec.args[0]`, it could be an arbitrary(but confined to a specific range) address. (7) A function is called with the out-of-bounds address in `chan`. (8) The out-of-bounds address is accessed. drivers/mailbox/mailbox.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c index 2acc6ec229a4..617ba505691d 100644 --- a/drivers/mailbox/mailbox.c +++ b/drivers/mailbox/mailbox.c @@ -489,12 +489,10 @@ EXPORT_SYMBOL_GPL(mbox_free_channel); static struct mbox_chan *fw_mbox_index_xlate(struct mbox_controller *mbox, const struct fwnode_reference_args *sp) { - int ind = sp->args[0]; - - if (ind >= mbox->num_chans) + if (sp->nargs < 1 || sp->args[0] >= mbox->num_chans) return ERR_PTR(-EINVAL); - return &mbox->chans[ind]; + return &mbox->chans[sp->args[0]]; } /** -- 2.52.0.487.g5c8c507ade-goog

15 hours, 4 minutes

1
0
0 0

[PATCH 5.4-6.6 v2] uio_hv_generic: Enable user space to manage interrupt_mask for subchannels

by Naman Jain

From: Long Li <longli(a)microsoft.com> Enable the user space to manage interrupt_mask for subchannels through irqcontrol interface for uio device. Also remove the memory barrier when monitor bit is enabled as it is not necessary. This is a backport of the upstream commit d062463edf17 ("uio_hv_generic: Set event for all channels on the device") with some modifications to resolve merge conflicts and take care of missing support for slow devices on older kernels. Original change was not a fix, but it needs to be backported to fix a NULL pointer crash resulting from missing interrupt mask setting. Commit b15b7d2a1b09 ("uio_hv_generic: Let userspace take care of interrupt mask") removed the default setting of interrupt_mask for channels (including subchannels) in the uio_hv_generic driver, as it relies on the user space to take care of managing it. This approach works fine when user space can control this setting using the irqcontrol interface provided for uio devices. Support for setting the interrupt mask through this interface for subchannels came only after commit d062463edf17 ("uio_hv_generic: Set event for all channels on the device"). On older kernels, this change is not present. With uio_hv_generic no longer setting the interrupt_mask, and userspace not having the capability to set it, it remains unset, and interrupts can come for the subchannels, which can result in a crash in hv_uio_channel_cb. Backport the change to older kernels, where this change was not present, to allow userspace to set the interrupt mask properly for subchannels. Additionally, this patch also adds certain checks for primary vs subchannels in the hv_uio_channel_cb, which can gracefully handle these two cases and prevent the NULL pointer crashes. Signed-off-by: Long Li <longli(a)microsoft.com> Fixes: b15b7d2a1b09 ("uio_hv_generic: Let userspace take care of interrupt mask") Closes: https://bugs.debian.org/1120602 Cc: stable(a)vger.kernel.org # all LTS kernels from 5.4 till 6.6 Signed-off-by: Naman Jain <namjain(a)linux.microsoft.com> --- Changes since v1: https://lore.kernel.org/all/20251115085937.2237-1-namjain@linux.microsoft.c… * Changed commit being fixed, to reflect upstream commit * Added stable kernel versions info in Stable tag and email subject. This needs to be ported to all the stable kernels, where the Fixes patch went in - 5.4.x, 5.10.x, 5.15.x, 6.1.x, 6.6.x. Previous notes: Remove reviewed-by tags since the original code has changed quite a bit while backporting. Backported change for 6.12 kernel is sent separately. --- drivers/uio/uio_hv_generic.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c index 137109f5f69b..95c1f08028a3 100644 --- a/drivers/uio/uio_hv_generic.c +++ b/drivers/uio/uio_hv_generic.c @@ -80,9 +80,15 @@ hv_uio_irqcontrol(struct uio_info *info, s32 irq_state) { struct hv_uio_private_data *pdata = info->priv; struct hv_device *dev = pdata->device; + struct vmbus_channel *primary, *sc; - dev->channel->inbound.ring_buffer->interrupt_mask = !irq_state; - virt_mb(); + primary = dev->channel; + primary->inbound.ring_buffer->interrupt_mask = !irq_state; + + mutex_lock(&vmbus_connection.channel_mutex); + list_for_each_entry(sc, &primary->sc_list, sc_list) + sc->inbound.ring_buffer->interrupt_mask = !irq_state; + mutex_unlock(&vmbus_connection.channel_mutex); return 0; } @@ -93,11 +99,18 @@ hv_uio_irqcontrol(struct uio_info *info, s32 irq_state) static void hv_uio_channel_cb(void *context) { struct vmbus_channel *chan = context; - struct hv_device *hv_dev = chan->device_obj; - struct hv_uio_private_data *pdata = hv_get_drvdata(hv_dev); + struct hv_device *hv_dev; + struct hv_uio_private_data *pdata; virt_mb(); + /* + * The callback may come from a subchannel, in which case look + * for the hv device in the primary channel + */ + hv_dev = chan->primary_channel ? + chan->primary_channel->device_obj : chan->device_obj; + pdata = hv_get_drvdata(hv_dev); uio_event_notify(&pdata->info); } -- 2.43.0

15 hours, 7 minutes

1
0
0 0

[PATCH 6.6 and older] uio_hv_generic: Enable user space to manage interrupt_mask for subchannels

by Naman Jain

From: Long Li <longli(a)microsoft.com> Enable the user space to manage interrupt_mask for subchannels through irqcontrol interface for uio device. Also remove the memory barrier when monitor bit is enabled as it is not necessary. This is a backport of the upstream commit d062463edf17 ("uio_hv_generic: Set event for all channels on the device") with some modifications to resolve merge conflicts and take care of missing support for slow devices on older kernels. Original change was not a fix, but it needs to be backported to fix a NULL pointer crash resulting from missing interrupt mask setting. Commit 37bd91f22794 ("uio_hv_generic: Let userspace take care of interrupt mask") removed the default setting of interrupt_mask for channels (including subchannels) in the uio_hv_generic driver, as it relies on the user space to take care of managing it. This approach works fine when user space can control this setting using the irqcontrol interface provided for uio devices. Support for setting the interrupt mask through this interface for subchannels came only after commit d062463edf17 ("uio_hv_generic: Set event for all channels on the device"). On older kernels, this change is not present. With uio_hv_generic no longer setting the interrupt_mask, and userspace not having the capability to set it, it remains unset, and interrupts can come for the subchannels, which can result in a crash in hv_uio_channel_cb. Backport the change to older kernels, where this change was not present, to allow userspace to set the interrupt mask properly for subchannels. Additionally, this patch also adds certain checks for primary vs subchannels in the hv_uio_channel_cb, which can gracefully handle these two cases and prevent the NULL pointer crashes. Signed-off-by: Long Li <longli(a)microsoft.com> Fixes: 37bd91f22794 ("uio_hv_generic: Let userspace take care of interrupt mask") Closes: https://bugs.debian.org/1120602 Cc: <stable(a)vger.kernel.org> # 6.6.x and older Signed-off-by: Naman Jain <namjain(a)linux.microsoft.com> --- Remove reviewed-by tags since the original code has changed quite a bit while backporting. Backported change for 6.12 kernel is sent separately. --- drivers/uio/uio_hv_generic.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c index 2724656bf634..69e5016ebd46 100644 --- a/drivers/uio/uio_hv_generic.c +++ b/drivers/uio/uio_hv_generic.c @@ -80,9 +80,15 @@ hv_uio_irqcontrol(struct uio_info *info, s32 irq_state) { struct hv_uio_private_data *pdata = info->priv; struct hv_device *dev = pdata->device; + struct vmbus_channel *primary, *sc; - dev->channel->inbound.ring_buffer->interrupt_mask = !irq_state; - virt_mb(); + primary = dev->channel; + primary->inbound.ring_buffer->interrupt_mask = !irq_state; + + mutex_lock(&vmbus_connection.channel_mutex); + list_for_each_entry(sc, &primary->sc_list, sc_list) + sc->inbound.ring_buffer->interrupt_mask = !irq_state; + mutex_unlock(&vmbus_connection.channel_mutex); return 0; } @@ -93,11 +99,18 @@ hv_uio_irqcontrol(struct uio_info *info, s32 irq_state) static void hv_uio_channel_cb(void *context) { struct vmbus_channel *chan = context; - struct hv_device *hv_dev = chan->device_obj; - struct hv_uio_private_data *pdata = hv_get_drvdata(hv_dev); + struct hv_device *hv_dev; + struct hv_uio_private_data *pdata; virt_mb(); + /* + * The callback may come from a subchannel, in which case look + * for the hv device in the primary channel + */ + hv_dev = chan->primary_channel ? + chan->primary_channel->device_obj : chan->device_obj; + pdata = hv_get_drvdata(hv_dev); uio_event_notify(&pdata->info); } -- 2.34.1

15 hours, 11 minutes

3
3
0 0

[REGRESSION 6.12.y] hyper-v: BUG: kernel NULL pointer dereference, address: 00000000000000a0: RIP: 0010:hv_uio_channel_cb+0xd/0x20 [uio_hv_generic]

by Salvatore Bonaccorso

Peter Morrow reported in Debian a regression, reported in https://bugs.debian.org/1120602 . The regression was seen after updating, to 6.12.57-1 in Debian, but details on the offending commit follows. His report was as follows: > Dear Maintainer, > > I'm seeing a kernel crash quite soon after boot on a debian trixie based > system running 6.12.57+deb13-amd64, unfortunately the kernel panics before > I can access the system to gather more information. Thus I'll provide details > of the system using a previously known good version. The panic is happening > 100% of the time unfortunately. I have access to the serial console however > so can enable any required verbose logging during boot if necessary. > > Crucially the crash is not seen with kernel version 6.12.41+deb13-amd64 with the > same userspace. We had pinned to that version until very recently to in order > to work around https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109676 > > I'm running a dpdk application here (VPP) on Azure, VM form factor is a > "Standard DS3 v2 (4 vcpus, 14 GiB memory)". > > The only relevant upstream commit in this area (as far as I can see) is: > > https://lore.kernel.org/linux-hyperv/1bb599ee-fe28-409d-b430-2fc086268936@l… > > The comment regarding avoiding races at start adds a bit more weight behind this > hunch, though it's only a hunch as I am most definitely nowhere near an expert > in this area. > > -- Package-specific info: > > [ 19.625535] BUG: kernel NULL pointer dereference, address: 00000000000000a0 > [ 19.628874] #PF: supervisor read access in kernel mode > [ 19.630841] #PF: error_code(0x0000) - not-present page > [ 19.632788] PGD 0 P4D 0 > [ 19.633905] Oops: Oops: 0000 [#1] PREEMPT SMP PTI > [ 19.635586] CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.12.57+deb13-amd64 #1 Debian 6.12.57-1 > [ 19.640216] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 > [ 19.644514] RIP: 0010:hv_uio_channel_cb+0xd/0x20 [uio_hv_generic] > [ 19.646994] Code: 02 00 00 5b 5d e9 53 98 69 e9 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 8b 47 10 <48> 8b b8 a0 00 00 00 f0 83 44 24 fc 00 e9 51 6f fa ff 90 90 90 90 > [ 19.654377] RSP: 0018:ffffb15ac01a4fa8 EFLAGS: 00010046 > [ 19.656385] RAX: 0000000000000000 RBX: 0000000000000015 RCX: 0000000000000015 > [ 19.659240] RDX: 0000000000000001 RSI: ffffffffffffffff RDI: ffff8ff69c759400 > [ 19.662168] RBP: ffff8ff548790200 R08: ffff8ff548790200 R09: 00fca75150b080e9 > [ 19.665239] R10: 0000000000000000 R11: ffffb15ac01a4ff8 R12: ffff8ff871dc1480 > [ 19.668193] R13: ffff8ff69c759400 R14: ffff8ff69c7596a0 R15: ffffffffc106e160 > [ 19.671106] FS: 0000000000000000(0000) GS:ffff8ff871d80000(0000) knlGS:0000000000000000 > [ 19.674281] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 19.676533] CR2: 00000000000000a0 CR3: 0000000100ba6003 CR4: 00000000003706f0 > [ 19.679385] Call Trace: > [ 19.680361] <IRQ> > [ 19.681181] vmbus_isr+0x1a5/0x210 [hv_vmbus] > [ 19.682916] __sysvec_hyperv_callback+0x32/0x60 > [ 19.684991] sysvec_hyperv_callback+0x6c/0x90 > [ 19.686665] </IRQ> > [ 19.687509] <TASK> > [ 19.688366] asm_sysvec_hyperv_callback+0x1a/0x20 > [ 19.690262] RIP: 0010:pv_native_safe_halt+0xf/0x20 > [ 19.692067] Code: 09 e9 c5 08 01 00 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d e5 3b 31 00 fb f4 <c3> cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 > [ 19.699119] RSP: 0018:ffffb15ac0103ed8 EFLAGS: 00000246 > [ 19.701412] RAX: 0000000000000003 RBX: ffff8ff5403b1fc0 RCX: ffff8ff54c64ce30 > [ 19.704328] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 000000000001f894 > [ 19.706910] RBP: 0000000000000003 R08: 000000000bb760d9 R09: 00fca75150b080e9 > [ 19.709762] R10: 0000000000000003 R11: 0000000000000001 R12: 0000000000000000 > [ 19.712510] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > [ 19.715173] default_idle+0x9/0x20 > [ 19.716846] default_idle_call+0x29/0x100 > [ 19.718623] do_idle+0x1fe/0x240 > [ 19.720045] cpu_startup_entry+0x29/0x30 > [ 19.721595] start_secondary+0x11e/0x140 > [ 19.723080] common_startup_64+0x13e/0x141 > [ 19.725222] </TASK> > [ 19.726387] Modules linked in: isofs cdrom uio_hv_generic uio binfmt_misc intel_rapl_msr intel_rapl_common intel_uncore_frequency_common isst_if_mbox_msr isst_if_common rpcrdma skx_edac_common nfit sunrpc libnvdimm crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 sha256_ssse3 rdma_ucm ib_iser sha1_ssse3 rdma_cm aesni_intel iw_cm gf128mul crypto_simd libiscsi cryptd ib_umad ib_ipoib scsi_transport_iscsi ib_cm rapl sg hv_utils hv_balloon evdev pcspkr joydev mpls_router ip_tunnel ramoops configfs pstore_blk efi_pstore pstore_zone nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs ip_tables x_tables autofs4 overlay squashfs dm_verity dm_bufio reed_solomon dm_mod loop ext4 crc16 mbcache jbd2 crc32c_generic mlx5_ib ib_uverbs ib_core mlx5_core mlxfw pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper sd_mod drm_kms_helper hv_storvsc scsi_transport_fc drm scsi_mod hid_generic hid_hyperv hid serio_raw hv_netvsc hyperv_keyboard scsi_common hv_vmbus > [ 19.726466] crc32_pclmul crc32c_intel > [ 19.765771] CR2: 00000000000000a0 > [ 19.767524] ---[ end trace 0000000000000000 ]--- > [ 19.800433] RIP: 0010:hv_uio_channel_cb+0xd/0x20 [uio_hv_generic] > [ 19.803170] Code: 02 00 00 5b 5d e9 53 98 69 e9 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 8b 47 10 <48> 8b b8 a0 00 00 00 f0 83 44 24 fc 00 e9 51 6f fa ff 90 90 90 90 > [ 19.811041] RSP: 0018:ffffb15ac01a4fa8 EFLAGS: 00010046 > [ 19.813466] RAX: 0000000000000000 RBX: 0000000000000015 RCX: 0000000000000015 > [ 19.816504] RDX: 0000000000000001 RSI: ffffffffffffffff RDI: ffff8ff69c759400 > [ 19.819484] RBP: ffff8ff548790200 R08: ffff8ff548790200 R09: 00fca75150b080e9 > [ 19.822625] R10: 0000000000000000 R11: ffffb15ac01a4ff8 R12: ffff8ff871dc1480 > [ 19.825569] R13: ffff8ff69c759400 R14: ffff8ff69c7596a0 R15: ffffffffc106e160 > [ 19.828804] FS: 0000000000000000(0000) GS:ffff8ff871d80000(0000) knlGS:0000000000000000 > [ 19.832214] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 19.834709] CR2: 00000000000000a0 CR3: 0000000100ba6003 CR4: 00000000003706f0 > [ 19.837976] Kernel panic - not syncing: Fatal exception in interrupt > [ 19.841825] Kernel Offset: 0x28a00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) > [ 19.896620] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- > > > lspci output: > > Collected from a system that is not crashing (6.12.41+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.41-1 (2025-08-12) x86_64 GNU/Linux)... > > $ sudo lspci -v > 2f22:00:02.0 Ethernet controller: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] (rev 80) > Subsystem: Mellanox Technologies Device 0190 > Physical Slot: 3 > Flags: bus master, fast devsel, latency 0, NUMA node 0 > Memory at fe0100000 (64-bit, prefetchable) [size=1M] > Capabilities: [60] Express Endpoint, IntMsgNum 0 > Capabilities: [9c] MSI-X: Enable+ Count=8 Masked- > Kernel driver in use: mlx5_core > Kernel modules: mlx5_core > > 52f7:00:02.0 Ethernet controller: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] (rev 80) > Subsystem: Mellanox Technologies Device 0190 > Physical Slot: 2 > Flags: bus master, fast devsel, latency 0, NUMA node 0 > Memory at fe0000000 (64-bit, prefetchable) [size=1M] > Capabilities: [60] Express Endpoint, IntMsgNum 0 > Capabilities: [9c] MSI-X: Enable+ Count=8 Masked- > Kernel driver in use: mlx5_core > Kernel modules: mlx5_core > > 7852:00:02.0 Ethernet controller: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] (rev 80) > Subsystem: Mellanox Technologies Device 0190 > Physical Slot: 4 > Flags: bus master, fast devsel, latency 0, NUMA node 0 > Memory at fe0200000 (64-bit, prefetchable) [size=1M] > Capabilities: [60] Express Endpoint, IntMsgNum 0 > Capabilities: [9c] MSI-X: Enable+ Count=8 Masked- > Kernel driver in use: mlx5_core > Kernel modules: mlx5_core > > dmidecode output: > > $ sudo dmidecode > # dmidecode 3.6 > Getting SMBIOS data from sysfs. > SMBIOS 3.1.0 present. > Table at 0x3FF82000. > > Handle 0x0000, DMI type 0, 26 bytes > BIOS Information > Vendor: Microsoft Corporation > Version: Hyper-V UEFI Release v4.1 > Release Date: 05/13/2024 > ROM Size: 64 kB > Characteristics: > BIOS characteristics not supported > ACPI is supported > Targeted content distribution is supported > UEFI is supported > System is a virtual machine > BIOS Revision: 4.1 > > Handle 0x0001, DMI type 1, 27 bytes > System Information > Manufacturer: Microsoft Corporation > Product Name: Virtual Machine > Version: Hyper-V UEFI Release v4.1 > Serial Number: 0000-0010-5437-9499-5225-4477-46 > UUID: 925315af-4af4-4d42-915a-1516b5a1fe5c > Wake-up Type: Power Switch > SKU Number: None > Family: Virtual Machine > > Handle 0x0002, DMI type 3, 24 bytes > Chassis Information > Manufacturer: Microsoft Corporation > Type: Desktop > Lock: Not Present > Version: Hyper-V UEFI Release v4.1 > Serial Number: 2466-9316-1078-9783-6078-7718-80 > Asset Tag: 7783-7084-3265-9085-8269-3286-77 > Boot-up State: Safe > Power Supply State: Safe > Thermal State: Safe > Security Status: Unknown > OEM Information: 0x00000000 > Height: Unspecified > Number Of Power Cords: Unspecified > Contained Elements: 0 > SKU Number: Virtual Machine > > Handle 0x0003, DMI type 2, 17 bytes > Base Board Information > Manufacturer: Microsoft Corporation > Product Name: Virtual Machine > Version: Hyper-V UEFI Release v4.1 > Serial Number: 0000-0010-4737-0707-0684-2660-76 > Asset Tag: None > Features: > Board is a hosting board > Location In Chassis: Virtual Machine > Chassis Handle: 0x0002 > Type: Motherboard > Contained Object Handles: 0 > > Handle 0x0004, DMI type 4, 48 bytes > Processor Information > Socket Designation: None > Type: Central Processor > Family: Unknown > Manufacturer: None > ID: 00 00 00 00 00 00 00 00 > Version: None > Voltage: Unknown > External Clock: Unknown > Max Speed: Unknown > Current Speed: Unknown > Status: Unpopulated > Upgrade: Other > L1 Cache Handle: Not Provided > L2 Cache Handle: Not Provided > L3 Cache Handle: Not Provided > Serial Number: None > Asset Tag: None > Part Number: None > Core Count: 4 > Core Enabled: 4 > Thread Count: 1 > Characteristics: None > > Handle 0x0005, DMI type 11, 5 bytes > OEM Strings > String 1: [MS_VM_CERT/SHA1/9b80ca0d5dd061ec9da4e494f4c3fd1196270c22] > String 2: None > String 3: To be filled by OEM > > Handle 0x0006, DMI type 16, 23 bytes > Physical Memory Array > Location: System Board Or Motherboard > Use: System Memory > Error Correction Type: None > Maximum Capacity: 0 bytes > Error Information Handle: Not Provided > Number Of Devices: 3 > > Handle 0x0007, DMI type 17, 92 bytes > Memory Device > Array Handle: 0x0006 > Error Information Handle: Not Provided > Total Width: Unknown > Data Width: Unknown > Size: 26 MB > Form Factor: Unknown > Set: None > Locator: M0001 > Bank Locator: None > Type: Unknown > Type Detail: Unknown > Speed: Unknown > Manufacturer: Microsoft Corporation > Serial Number: None > Asset Tag: None > Part Number: None > Rank: Unknown > Configured Memory Speed: Unknown > Minimum Voltage: Unknown > Maximum Voltage: Unknown > Configured Voltage: Unknown > Memory Technology: <OUT OF SPEC> > Memory Operating Mode Capability: None > Firmware Version: Not Specified > Module Manufacturer ID: Unknown > Module Product ID: Unknown > Memory Subsystem Controller Manufacturer ID: Unknown > Memory Subsystem Controller Product ID: Unknown > Non-Volatile Size: None > Volatile Size: None > Cache Size: None > Logical Size: None > > Handle 0x0008, DMI type 19, 31 bytes > Memory Array Mapped Address > Starting Address: 0x00000000000 > Ending Address: 0x00001A003FF > Range Size: 26625 kB > Physical Array Handle: 0x0006 > Partition Width: 0 > > Handle 0x0009, DMI type 20, 35 bytes > Memory Device Mapped Address > Starting Address: 0x00000000000 > Ending Address: 0x00001A003FF > Range Size: 26625 kB > Physical Device Handle: 0x0007 > Memory Array Mapped Address Handle: 0x0008 > Partition Row Position: Unknown > > Handle 0x000A, DMI type 17, 92 bytes > Memory Device > Array Handle: 0x0006 > Error Information Handle: Not Provided > Total Width: Unknown > Data Width: Unknown > Size: 948 MB > Form Factor: Unknown > Set: None > Locator: M0002 > Bank Locator: None > Type: Unknown > Type Detail: Unknown > Speed: Unknown > Manufacturer: Microsoft Corporation > Serial Number: None > Asset Tag: None > Part Number: None > Rank: Unknown > Configured Memory Speed: Unknown > Minimum Voltage: Unknown > Maximum Voltage: Unknown > Configured Voltage: Unknown > Memory Technology: <OUT OF SPEC> > Memory Operating Mode Capability: None > Firmware Version: Not Specified > Module Manufacturer ID: Unknown > Module Product ID: Unknown > Memory Subsystem Controller Manufacturer ID: Unknown > Memory Subsystem Controller Product ID: Unknown > Non-Volatile Size: None > Volatile Size: None > Cache Size: None > Logical Size: None > > Handle 0x000B, DMI type 19, 31 bytes > Memory Array Mapped Address > Starting Address: 0x00004C00000 > Ending Address: 0x000400003FF > Range Size: 970753 kB > Physical Array Handle: 0x0006 > Partition Width: 0 > > Handle 0x000C, DMI type 20, 35 bytes > Memory Device Mapped Address > Starting Address: 0x00004C00000 > Ending Address: 0x000400003FF > Range Size: 970753 kB > Physical Device Handle: 0x000A > Memory Array Mapped Address Handle: 0x000B > Partition Row Position: Unknown > > Handle 0x000D, DMI type 17, 92 bytes > Memory Device > Array Handle: 0x0006 > Error Information Handle: Not Provided > Total Width: Unknown > Data Width: Unknown > Size: 13 GB > Form Factor: Unknown > Set: None > Locator: M0003 > Bank Locator: None > Type: Unknown > Type Detail: Unknown > Speed: Unknown > Manufacturer: Microsoft Corporation > Serial Number: None > Asset Tag: None > Part Number: None > Rank: Unknown > Configured Memory Speed: Unknown > Minimum Voltage: Unknown > Maximum Voltage: Unknown > Configured Voltage: Unknown > Memory Technology: <OUT OF SPEC> > Memory Operating Mode Capability: None > Firmware Version: Not Specified > Module Manufacturer ID: Unknown > Module Product ID: Unknown > Memory Subsystem Controller Manufacturer ID: Unknown > Memory Subsystem Controller Product ID: Unknown > Non-Volatile Size: None > Volatile Size: None > Cache Size: None > Logical Size: None > > Handle 0x000E, DMI type 19, 31 bytes > Memory Array Mapped Address > Starting Address: 0x00100000000 > Ending Address: 0x004400003FF > Range Size: 13 GB > Physical Array Handle: 0x0006 > Partition Width: 0 > > Handle 0x000F, DMI type 20, 35 bytes > Memory Device Mapped Address > Starting Address: 0x00100000000 > Ending Address: 0x004400003FF > Range Size: 13 GB > Physical Device Handle: 0x000D > Memory Array Mapped Address Handle: 0x000E > Partition Row Position: Unknown > > Handle 0x0010, DMI type 32, 11 bytes > System Boot Information > Status: No errors detected > > Handle 0xFEFF, DMI type 127, 4 bytes > End Of Table The offending commit appers to be the backport of b15b7d2a1b09 ("uio_hv_generic: Let userspace take care of interrupt mask") for 6.12.y. Peter confirmed that reverting this commit on top of 6.12.57-1 as packaged in Debian resolves indeed the issue. Interestingly the issue is *not* seen with 6.17.7 based kernel in Debian. #regzbot introduced: 37bd91f22794dc05436130d6983302cb90ecfe7e #regzbot monitor: https://bugs.debian.org/1120602 Thank you already! Regards, Salvatore

15 hours, 11 minutes

3
7
0 0

[PATCH] usb: dwc3: keep susphy enabled during exit to avoid controller faults

by Udipto Goswami

On some platforms, switching USB roles from host to device can trigger controller faults due to premature PHY power-down. This occurs when the PHY is disabled too early during teardown, causing synchronization issues between the PHY and controller. Keep susphy enabled during dwc3_host_exit() and dwc3_gadget_exit() ensures the PHY remains in a low-power state capable of handling required commands during role switch. Cc: stable(a)vger.kernel.org Fixes: 6d735722063a ("usb: dwc3: core: Prevent phy suspend during init") Suggested-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Signed-off-by: Udipto Goswami <udipto.goswami(a)oss.qualcomm.com> --- drivers/usb/dwc3/gadget.c | 2 +- drivers/usb/dwc3/host.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 321361288935..34c5a4de612e 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -4804,7 +4804,7 @@ void dwc3_gadget_exit(struct dwc3 *dwc) if (!dwc->gadget) return; - dwc3_enable_susphy(dwc, false); + dwc3_enable_susphy(dwc, true); usb_del_gadget(dwc->gadget); dwc3_gadget_free_endpoints(dwc); usb_put_gadget(dwc->gadget); diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c index 1c513bf8002e..0c171118bd55 100644 --- a/drivers/usb/dwc3/host.c +++ b/drivers/usb/dwc3/host.c @@ -223,7 +223,7 @@ void dwc3_host_exit(struct dwc3 *dwc) if (dwc->sys_wakeup) device_init_wakeup(&dwc->xhci->dev, false); - dwc3_enable_susphy(dwc, false); + dwc3_enable_susphy(dwc, true); platform_device_unregister(dwc->xhci); dwc->xhci = NULL; } -- 2.34.1

15 hours, 44 minutes

1
0
0 0

[PATCH v3] Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref

by Douglas Anderson

In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed). Reported-by: IncogCyberpunk <incogcyberpunk(a)proton.me> Closes: http://lore.kernel.org/r/a380d061-479e-4713-bddd-1d6571ca7e86@leemhuis.info Fixes: e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()") Cc: stable(a)vger.kernel.org Tested-by: IncogCyberpunk <incogcyberpunk(a)proton.me> Signed-off-by: Douglas Anderson <dianders(a)chromium.org> --- Changes in v3: - Added Cc to stable. - Added IncogCyberpunk Tested-by tag. - v2: https://patch.msgid.link/20251119092641.v2.1.I1ae7aebc967e52c7c4be7aa65fbd8… Changes in v2: - Rebase atop commit 529ac8e706c3 ("Bluetooth: ... mtk iso interface") - v1: https://patch.msgid.link/20251119085354.1.I1ae7aebc967e52c7c4be7aa65fbd8173… drivers/bluetooth/btusb.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index fcc62e2fb641..683ac02e964b 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -2751,6 +2751,11 @@ static void btusb_mtk_claim_iso_intf(struct btusb_data *data) if (!btmtk_data) return; + if (!btmtk_data->isopkt_intf) { + bt_dev_err(data->hdev, "Can't claim NULL iso interface"); + return; + } + /* * The function usb_driver_claim_interface() is documented to need * locks held if it's not called from a probe routine. The code here -- 2.52.0.rc1.455.g30608eb744-goog

16 hours, 12 minutes

6
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror