Page 316 of 2475 results (0.015 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: exfat: fix overflow for large capacity partition Using int type for sector index, there will be overflow in a large capacity partition. For example, if storage with sector size of 512 bytes and partition capacity is larger than 2TB, there will be overflow. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exfat: corrige el desbordamiento de una partición de gran capacidad. Al usar el tipo int para el índice del sector, habrá un desbordamiento en una partición de gran capacidad. Por ejemplo, si el almacenamiento con un tamaño de sector de 512 bytes y una capacidad de partición es superior a 2 TB, se producirá un desbordamiento. • https://git.kernel.org/stable/c/1b6138385499507147e8f654840f4c39afe6adbf https://git.kernel.org/stable/c/17244f71765dfec39e84493993993e896c376d09 https://git.kernel.org/stable/c/2e9ceb6728f1dc2fa4b5d08f37d88cbc49a20a62 •

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

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix hang during unmount when stopping a space reclaim worker Often when running generic/562 from fstests we can hang during unmount, resulting in a trace like this: Sep 07 11:52:00 debian9 unknown: run fstests generic/562 at 2022-09-07 11:52:00 Sep 07 11:55:32 debian9 kernel: INFO: task umount:49438 blocked for more than 120 seconds. Sep 07 11:55:32 debian9 kernel: Not tainted 6.0.0-rc2-btrfs-next-122 #1 Sep 07 11:55:32 debian9 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Sep 07 11:55:32 debian9 kernel: task:umount state:D stack: 0 pid:49438 ppid: 25683 flags:0x00004000 Sep 07 11:55:32 debian9 kernel: Call Trace: Sep 07 11:55:32 debian9 kernel: <TASK> Sep 07 11:55:32 debian9 kernel: __schedule+0x3c8/0xec0 Sep 07 11:55:32 debian9 kernel: ? rcu_read_lock_sched_held+0x12/0x70 Sep 07 11:55:32 debian9 kernel: schedule+0x5d/0xf0 Sep 07 11:55:32 debian9 kernel: schedule_timeout+0xf1/0x130 Sep 07 11:55:32 debian9 kernel: ? lock_release+0x224/0x4a0 Sep 07 11:55:32 debian9 kernel: ? lock_acquired+0x1a0/0x420 Sep 07 11:55:32 debian9 kernel: ? trace_hardirqs_on+0x2c/0xd0 Sep 07 11:55:32 debian9 kernel: __wait_for_common+0xac/0x200 Sep 07 11:55:32 debian9 kernel: ? • https://git.kernel.org/stable/c/d6fd0ae25c6495674dc5a41a8d16bc8e0073276d https://git.kernel.org/stable/c/1ec2bf44c3770b9c3d510b1e78d50cd7fd19e8c5 https://git.kernel.org/stable/c/b4c7c826709b7d882ec9b264d5032e887e6bd720 https://git.kernel.org/stable/c/6ac5b52e3f352f9cb270c89e6e1d4dadb564ddb8 https://git.kernel.org/stable/c/d8a76a2e514fbbb315a6dfff2d342de2de833994 https://git.kernel.org/stable/c/c338bea1fec5504290dc0acf026c9e7dba25004b https://git.kernel.org/stable/c/a362bb864b8db4861977d00bd2c3222503ccc34b •

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

In the Linux kernel, the following vulnerability has been resolved: gpio: mockup: fix NULL pointer dereference when removing debugfs We now remove the device's debugfs entries when unbinding the driver. This now causes a NULL-pointer dereference on module exit because the platform devices are unregistered *after* the global debugfs directory has been recursively removed. Fix it by unregistering the devices first. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gpio: maqueta: corrige la desreferencia del puntero NULL al eliminar debugfs Ahora eliminamos las entradas debugfs del dispositivo al desvincular el controlador. Esto ahora provoca una desreferencia del puntero NULL al salir del módulo porque los dispositivos de la plataforma no están registrados *después* de que el directorio global debugfs se haya eliminado de forma recursiva. Solucionarlo cancelando el registro de los dispositivos primero. • https://git.kernel.org/stable/c/3815e66c2183f3430490e450ba16779cf5214ec6 https://git.kernel.org/stable/c/3a10e8edee2b45a654f1f7b05f747129ec84cf9d https://git.kernel.org/stable/c/bc55c1677edbe86a1c66a35e800df47dff16ad61 https://git.kernel.org/stable/c/bdea98b98f844bd8a983ca880893e509a8b4162f https://git.kernel.org/stable/c/18352095a0d581f6aeb1e9fc9d68cc0152cd64b4 https://git.kernel.org/stable/c/af0bfabf06c74c260265c30ba81a34e7dec0e881 https://git.kernel.org/stable/c/b7df41a6f79dfb18ba2203f8c5f0e9c0b9b57f68 •

CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Really move i915_gem_context.link under ref protection i915_perf assumes that it can use the i915_gem_context reference to protect its i915->gem.contexts.list iteration. However, this requires that we do not remove the context from the list until after we drop the final reference and release the struct. If, as currently, we remove the context from the list during context_close(), the link.next pointer may be poisoned while we are holding the context reference and cause a GPF: [ 4070.573157] i915 0000:00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering on ctx_id=0x1fffff ctx_id_mask=0x1fffff [ 4070.574881] general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP [ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: G E 5.17.9 #180 [ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017 [ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915] [ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 f0 41 0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 <49> 8b 45 50 48 8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff [ 4070.574990] RSP: 0018:ffffc90002077b78 EFLAGS: 00010202 [ 4070.574995] RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000000 [ 4070.575000] RDX: 0000000000000001 RSI: ffffc90002077b20 RDI: ffff88810ddc7c68 [ 4070.575004] RBP: 0000000000000001 R08: ffff888103242648 R09: fffffffffffffffc [ 4070.575008] R10: ffffffff82c50bc0 R11: 0000000000025c80 R12: ffff888101bf1860 [ 4070.575012] R13: dead0000000000b0 R14: ffffc90002077c04 R15: ffff88810be5cabc [ 4070.575016] FS: 00007f1ed50c0780(0000) GS:ffff88885ec80000(0000) knlGS:0000000000000000 [ 4070.575021] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4070.575025] CR2: 00007f1ed5590280 CR3: 000000010ef6f005 CR4: 00000000003706e0 [ 4070.575029] Call Trace: [ 4070.575033] <TASK> [ 4070.575037] lrc_configure_all_contexts+0x13e/0x150 [i915] [ 4070.575103] gen8_enable_metric_set+0x4d/0x90 [i915] [ 4070.575164] i915_perf_open_ioctl+0xbc0/0x1500 [i915] [ 4070.575224] ? asm_common_interrupt+0x1e/0x40 [ 4070.575232] ? i915_oa_init_reg_state+0x110/0x110 [i915] [ 4070.575290] drm_ioctl_kernel+0x85/0x110 [ 4070.575296] ? • https://git.kernel.org/stable/c/f8246cf4d9a9025d26c609bb2195e7c0a9ce5c40 https://git.kernel.org/stable/c/713fa3e4591f65f804bdc88e8648e219fabc9ee1 https://git.kernel.org/stable/c/f799e0568d6c153368b177e0bbbde7dcc4ce7f1d https://git.kernel.org/stable/c/d119888b09bd567e07c6b93a07f175df88857e02 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •

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

In the Linux kernel, the following vulnerability has been resolved: gpio: mockup: Fix potential resource leakage when register a chip If creation of software node fails, the locally allocated string array is left unfreed. Free it on error path. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gpio: maqueta: corrige una posible fuga de recursos al registrar un chip. Si falla la creación del nodo de software, la matriz de cadenas asignada localmente queda sin liberar. Libérelo en la ruta de error. • https://git.kernel.org/stable/c/6fda593f3082ef1aa783ac13e89f673fd69a2cb6 https://git.kernel.org/stable/c/9b26723e058faaf11b532fb4aa16d6849d581790 https://git.kernel.org/stable/c/41f857033c44442a27f591fda8d986e7c9e42872 https://git.kernel.org/stable/c/02743c4091ccfb246f5cdbbe3f44b152d5d12933 • CWE-404: Improper Resource Shutdown or Release •