Page 389 of 2886 results (0.014 seconds)

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ext4: avoid online resizing failures due to oversized flex bg When we online resize an ext4 filesystem with a oversized flexbg_size, mkfs.ext4 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16G the following WARN_ON is triggered: ================================================================== WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550 Modules linked in: sg(E) CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314 RIP: 0010:__alloc_pages+0x411/0x550 Call Trace: <TASK> __kmalloc_large_node+0xa2/0x200 __kmalloc+0x16e/0x290 ext4_resize_fs+0x481/0xd80 __ext4_ioctl+0x1616/0x1d90 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90 ================================================================== This is because flexbg_size is too large and the size of the new_group_data array to be allocated exceeds MAX_ORDER. Currently, the minimum value of MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding maximum number of groups that can be allocated is: (PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845 And the value that is down-aligned to the power of 2 is 16384. Therefore, this value is defined as MAX_RESIZE_BG, and the number of groups added each time does not exceed this value during resizing, and is added multiple times to complete the online resizing. The difference is that the metadata in a flex_bg may be more dispersed. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: evita fallos de cambio de tamaño en línea debido a flex bg sobredimensionado Cuando redimensionamos en línea un sistema de archivos ext4 con un flexbg_size sobredimensionado, mkfs.ext4 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16G se activa el siguiente WARN_ON: ===================================== ============================== ADVERTENCIA: CPU: 0 PID: 427 en mm/page_alloc.c:4402 __alloc_pages+0x411/ 0x550 Módulos vinculados en: sg(E) CPU: 0 PID: 427 Comm: resize2fs Contaminado: GE 6.6.0-rc5+ #314 RIP: 0010:__alloc_pages+0x411/0x550 Seguimiento de llamadas: __kmalloc_large_node+0xa2/0x200 __kmalloc+ 0x16e/0x290 text4_resize_fs+0x481/0xd80 __ext4_ioctl+0x1616/0x1d90 text4_ioctl+0x12/0x20 __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90 ======== =============== ============================================ Esto se debe a que flexbg_size también lo es grande y el tamaño de la matriz new_group_data que se asignará excede MAX_ORDER. • https://git.kernel.org/stable/c/cd1f93ca97a9136989f3bd2bf90696732a2ed644 https://git.kernel.org/stable/c/b183fe8702e78bba3dcef8e7193cab6898abee07 https://git.kernel.org/stable/c/cfbbb3199e71b63fc26cee0ebff327c47128a1e8 https://git.kernel.org/stable/c/d76c8d7ffe163c6bf2f1ef680b0539c2b3902b90 https://git.kernel.org/stable/c/6d2cbf517dcabc093159cf138ad5712c9c7fa954 https://git.kernel.org/stable/c/8b1413dbfe49646eda2c00c0f1144ee9d3368e0c https://git.kernel.org/stable/c/dc3e0f55bec4410f3d74352c4a7c79f518088ee2 https://git.kernel.org/stable/c/5d1935ac02ca5aee364a449a35e2977ea • CWE-131: Incorrect Calculation of Buffer Size •

CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers These three bpf_map_{lookup,update,delete}_elem() helpers are also available for sleepable bpf program, so add the corresponding lock assertion for sleepable bpf program, otherwise the following warning will be reported when a sleepable bpf program manipulates bpf map under interpreter mode (aka bpf_jit_enable=0): WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ...... CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:bpf_map_lookup_elem+0x54/0x60 ...... Call Trace: <TASK> ? __warn+0xa5/0x240 ? bpf_map_lookup_elem+0x54/0x60 ? report_bug+0x1ba/0x1f0 ? handle_bug+0x40/0x80 ? • https://git.kernel.org/stable/c/d6d6fe4bb105595118f12abeed4a7bdd450853f3 https://git.kernel.org/stable/c/483cb92334cd7f1d5387dccc0ab5d595d27a669d https://git.kernel.org/stable/c/c7f1b6146f4a46d727c0d046284c28b6882c6304 https://git.kernel.org/stable/c/169410eba271afc9f0fb476d996795aa26770c6d https://access.redhat.com/security/cve/CVE-2023-52621 https://bugzilla.redhat.com/show_bug.cgi?id=2271690 • CWE-413: Improper Resource Locking •

CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: tracing: Ensure visibility when inserting an element into tracing_map Running the following two commands in parallel on a multi-processor AArch64 machine can sporadically produce an unexpected warning about duplicate histogram entries: $ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc) The warning looks as follows: [ 2911.172474] ------------[ cut here ]------------ [ 2911.173111] Duplicates detected: 1 [ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408 [ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E) [ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1 [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018 [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408 [ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408 [ 2911.185310] sp : ffff8000a1513900 [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008 [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8 [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8 [ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000 [ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480 [ 2911.194259] Call trace: [ 2911.194626] tracing_map_sort_entries+0x3e0/0x408 [ 2911.195220] hist_show+0x124/0x800 [ 2911.195692] seq_read_iter+0x1d4/0x4e8 [ 2911.196193] seq_read+0xe8/0x138 [ 2911.196638] vfs_read+0xc8/0x300 [ 2911.197078] ksys_read+0x70/0x108 [ 2911.197534] __arm64_sys_read+0x24/0x38 [ 2911.198046] invoke_syscall+0x78/0x108 [ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8 [ 2911.199157] do_el0_svc+0x28/0x40 [ 2911.199613] el0_svc+0x40/0x178 [ 2911.200048] el0t_64_sync_handler+0x13c/0x158 [ 2911.200621] el0t_64_sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]--- The problem appears to be caused by CPU reordering of writes issued from __tracing_map_insert(). The check for the presence of an element with a given key in this function is: val = READ_ONCE(entry->val); if (val && keys_match(key, val->key, map->key_size)) ... The write of a new entry is: elt = get_free_elt(map); memcpy(elt->key, key, map->key_size); entry->val = elt; The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;" stores may become visible in the reversed order on another CPU. This second CPU might then incorrectly determine that a new key doesn't match an already present val->key and subse ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: garantiza la visibilidad al insertar un elemento en tracing_map La ejecución de los siguientes dos comandos en paralelo en una máquina multiprocesador AArch64 puede producir esporádicamente una advertencia inesperada sobre entradas de histograma duplicadas: $ while true ; hacer echo hist:key=id.syscall:val=hitcount &gt; \ /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist sleep 0.001 done $ estrés-ng --sysbadaddr $(nproc) La advertencia tiene el siguiente aspecto: [ 2911.172474] ------------[ cortar aquí ]------------ [ 2911.173111] Duplicados detectados: 1 [2911.173574] ADVERTENCIA: CPU: 2 PID: 12247 en kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408 [2911.174702] Módulos vinculados en: iscsi_ibft(E) iscsi_boot_sy sfs(E) rfkill(E ) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) botón(E) fusible(E) efi_pstore(E) ip_tables(E) x_tables (E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E ) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth (E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E) [ 2911.174738] Módulos contaminados descargados: cppc_cpufreq(E):1 [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: cargado Contaminado: GE 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [2911.182398] Nombre de hardware: Amazon EC2 c7g.8xlarge/, BIOS 1.0 1/11/2018 [2911.183208] pstate: 6140 0005 (nZCv daif +PAN -UAO -TCO +DIT - SSBS BTYPE=--) [ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408 [ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408 [ 2911.185310] sp : ffff8000a1513900 [ 2911.18 5750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 00000000000000008 [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.1883 10] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a151 34b8 [2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [ 2911.191716] x8 : 00 0000000017ffe8 x7: c0000000fffeffff x6: 000000000057ffa8 [2911.192554] x5: ffff0012f6c24ec0 x4: 00000000000000000 x3: ffff2e5b72b5d000 [2911.193 404] x2: 0000000000000000 x1: 0000000000000000 x0 : ffff0003ff254480 [2911.194259] Rastreo de llamadas: [2911.194626] tracing_map_sort_entries+0x3e0/0x408 [2911.195220] hist_show+0x124/0x800 [2911.195692] seq_read_iter+0x1d4 /0x4e8 [ 2911.196193] seq_read+0xe8/0x138 [ 2911.196638] vfs_read+0xc8/0x300 [ 2911.197078 ] ksys_read+0x70/0x108 [ 2911.197534] __arm64_sys_read+0x24/0x38 [ 2911.198046] invoke_syscall+0x78/0x108 [ 2911.198553] el0_svc_common.constprop.0+0xd0/0x f8 [ 2911.199157] do_el0_svc+0x28/0x40 [ 2911.199613] el0_svc+0x40/0x178 [ 2911.200048] el0t_64_sync_handler+0x13c/0x158 [ 2911.200621] el0t_64_sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]--- El problema parece deberse a la reordenación de la CPU de escrituras emitidas desde __tracing_map_insert(). La comprobación de la presencia de un elemento con una clave determinada en esta función es: val = READ_ONCE(entry-&gt;val); if (val &amp;&amp; llaves_match(key, val-&gt;key, map-&gt;key_size)) ... La escritura de una nueva entrada es: elt = get_free_elt(map); memcpy(elt-&gt;clave, clave, mapa-&gt;key_size); entrada-&gt;val = elt; El "memcpy(elt-&gt;key, key, map-&gt;key_size);" y "entrada-&gt;val = elt;" Las tiendas pueden volverse visibles en orden inverso en otra CPU.---truncada--- • https://git.kernel.org/stable/c/c193707dde77ace92a649cd59a17e105e2fbeaef https://git.kernel.org/stable/c/5022b331c041e8c54b9a6a3251579bd1e8c0fc0b https://git.kernel.org/stable/c/dad9b28f675ed99b4dec261db2a397efeb80b74c https://git.kernel.org/stable/c/ef70dfa0b1e5084f32635156c9a5c795352ad860 https://git.kernel.org/stable/c/aef1cb00856ccfd614467cfb50b791278992e177 https://git.kernel.org/stable/c/f4f7e696db0274ff560482cc52eddbf0551d4b7a https://git.kernel.org/stable/c/a1eebe76e187dbe11ca299f8dbb6e45d5b1889e7 https://git.kernel.org/stable/c/bf4aeff7da85c3becd39fb73bac941223 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •

CVSS: -EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: btrfs: don't abort filesystem when attempting to snapshot deleted subvolume If the source file descriptor to the snapshot ioctl refers to a deleted subvolume, we get the following abort: BTRFS: Transaction aborted (error -2) WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs] Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs] RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027 RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840 RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998 R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80 FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0 Call Trace: <TASK> ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? __warn+0x81/0x130 ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? report_bug+0x171/0x1a0 ? • https://git.kernel.org/stable/c/2bdf872bcfe629a6202ffd6641615a8ed00e8464 https://git.kernel.org/stable/c/0877497dc97834728e1b528ddf1e1c484292c29c https://git.kernel.org/stable/c/6e6bca99e8d88d989a7cde4c064abea552d5219b https://git.kernel.org/stable/c/ec794a7528199e1be6d47bec03f4755aa75df256 https://git.kernel.org/stable/c/d8680b722f0ff6d7a01ddacc1844e0d52354d6ff https://git.kernel.org/stable/c/7081929ab2572920e94d70be3d332e5c9f97095a https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: NFC: nci: fix memory leak in nci_allocate_device nfcmrvl_disconnect fails to free the hci_dev field in struct nci_dev. Fix this by freeing hci_dev in nci_free_device. BUG: memory leak unreferenced object 0xffff888111ea6800 (size 1024): comm "kworker/1:0", pid 19, jiffies 4294942308 (age 13.580s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 60 fd 0c 81 88 ff ff .........`...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000004bc25d43>] kmalloc include/linux/slab.h:552 [inline] [<000000004bc25d43>] kzalloc include/linux/slab.h:682 [inline] [<000000004bc25d43>] nci_hci_allocate+0x21/0xd0 net/nfc/nci/hci.c:784 [<00000000c59cff92>] nci_allocate_device net/nfc/nci/core.c:1170 [inline] [<00000000c59cff92>] nci_allocate_device+0x10b/0x160 net/nfc/nci/core.c:1132 [<00000000006e0a8e>] nfcmrvl_nci_register_dev+0x10a/0x1c0 drivers/nfc/nfcmrvl/main.c:153 [<000000004da1b57e>] nfcmrvl_probe+0x223/0x290 drivers/nfc/nfcmrvl/usb.c:345 [<00000000d506aed9>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [<00000000bc632c92>] really_probe+0x159/0x4a0 drivers/base/dd.c:554 [<00000000f5009125>] driver_probe_device+0x84/0x100 drivers/base/dd.c:740 [<000000000ce658ca>] __device_attach_driver+0xee/0x110 drivers/base/dd.c:846 [<000000007067d05f>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431 [<00000000f8e13372>] __device_attach+0x122/0x250 drivers/base/dd.c:914 [<000000009cf68860>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491 [<00000000359c965a>] device_add+0x5be/0xc30 drivers/base/core.c:3109 [<00000000086e4bd3>] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2164 [<00000000ca036872>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 [<00000000d40d36f6>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293 [<00000000bc632c92>] really_probe+0x159/0x4a0 drivers/base/dd.c:554 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFC: nci: corrige la pérdida de memoria en nci_allocate_device nfcmrvl_disconnect no logra liberar el campo hci_dev en la estructura nci_dev. Solucione este problema liberando hci_dev en nci_free_device. ERROR: pérdida de memoria, objeto sin referencia 0xffff888111ea6800 (tamaño 1024): comunicación "kworker/1:0", pid 19, jiffies 4294942308 (edad 13.580 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 60 fd 0c 81 88 ff ff .........`...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............. ... seguimiento: [&lt;000000004bc25d43&gt;] kmalloc include/linux/slab.h:552 [en línea] [&lt;000000004bc25d43&gt;] kzalloc include/linux/slab.h:682 [en línea] [&lt;000000004bc25d43&gt;] nci_hci_allocate+0x21/ 0xd0 net/nfc/nci/hci.c:784 [&lt;00000000c59cff92&gt;] nci_allocate_device net/nfc/nci/core.c:1170 [en línea] [&lt;00000000c59cff92&gt;] nci_allocate_device+0x10b/0x160 net/nfc/nci/core. c:1132 [&lt;00000000006e0a8e&gt;] nfcmrvl_nci_register_dev+0x10a/0x1c0 controladores/nfc/nfcmrvl/main.c:153 [&lt;000000004da1b57e&gt;] nfcmrvl_probe+0x223/0x290 controladores/nfc/nfcmr vl/usb.c:345 [&lt;00000000d506aed9&gt;] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [&lt;00000000bc632c92&gt;] very_probe+0x159/0x4a0 drivers/base/dd.c:554 [&lt;00000000f5009125&gt;] driver_probe_device+0x84/0x100 drivers/base/dd .c:740 [&lt;000000000ce658ca&gt;] __device_attach_driver+0xee/0x110 controladores/base/dd.c:846 [&lt;000000007067d05f&gt;] bus_for_each_drv+0xb7/0x100 controladores/base/bus.c:431 [&lt;00000000f8e1337 2&gt;] __device_attach+0x122 /0x250 controladores/base/dd.c:914 [&lt;000000009cf68860&gt;] bus_probe_device+0xc6/0xe0 controladores/base/bus.c:491 [&lt;00000000359c965a&gt;] dispositivo_add+0x5be/0xc30 controladores/base/core.c:3109 [ &lt;00000000086e4bd3&gt;] usb_set_configuration+0x9d9/0xb90 controladores/usb/core/message.c:2164 [&lt;00000000ca036872&gt;] usb_generic_driver_probe+0x8c/0xc0 controladores/usb/core/generic.c:238 [&lt;00000000d40d3 6f6&gt;] dispositivo_probe_usb+0x5c/ 0x140 controladores/usb/core/driver.c:293 [&lt;00000000bc632c92&gt;] very_probe+0x159/0x4a0 controladores/base/dd.c:554 • https://git.kernel.org/stable/c/11f54f228643d0248ec00ce8c9fb8d872f87e7b8 https://git.kernel.org/stable/c/448a1cb12977f52142e6feb12022c59662d88dc1 https://git.kernel.org/stable/c/4a621621c7af3cec21c47c349b30cd9c3cea11c8 https://git.kernel.org/stable/c/2c2fb2df46ea866b49fea5ec7112ec3cd4896c74 https://git.kernel.org/stable/c/0365701bc44e078682ee1224866a71897495c7ef https://git.kernel.org/stable/c/af2a4426baf71163c0c354580ae98c7888a9aba7 https://git.kernel.org/stable/c/b34cb7ac32cc8e5471dc773180ea9ae676b1a745 https://git.kernel.org/stable/c/65234f50a90b64b335cbb9164b8a98c2a •