Page 363 of 2370 results (0.010 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: Add protection for bmp length out of range UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts that are out of bounds for their data type. vmlinux get_bitmap(b=75) + 712 <net/netfilter/nf_conntrack_h323_asn1.c:0> vmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956 <net/netfilter/nf_conntrack_h323_asn1.c:592> vmlinux decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216 <net/netfilter/nf_conntrack_h323_asn1.c:814> vmlinux decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812 <net/netfilter/nf_conntrack_h323_asn1.c:576> vmlinux decode_choice(base=0xFFFFFFD008037280, level=0) + 1216 <net/netfilter/nf_conntrack_h323_asn1.c:814> vmlinux DecodeRasMessage() + 304 <net/netfilter/nf_conntrack_h323_asn1.c:833> vmlinux ras_help() + 684 <net/netfilter/nf_conntrack_h323_main.c:1728> vmlinux nf_confirm() + 188 <net/netfilter/nf_conntrack_proto.c:137> Due to abnormal data in skb->data, the extension bitmap length exceeds 32 when decoding ras message then uses the length to make a shift operation. It will change into negative after several loop. UBSAN load could detect a negative shift as an undefined behaviour and reports exception. So we add the protection to avoid the length exceeding 32. Or else it will return out of range error and stop decoding. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nf_conntrack_h323: Agregar protección para longitud de bmp fuera de rango La carga de UBSAN informa una excepción de BRK#5515 SHIFT_ISSUE: desplazamientos bit a bit que están fuera de los límites para su tipo de datos. vmlinux get_bitmap(b=75) + 712 vmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, nivel=134443100) + 1956 vmlinux decode_choice (base=0xFFFFFFD0080370F0, nivel=23843636) + 1216 vmlinux decode_seq(f=0xFFFFFFD0080371A8, nivel=134443500) + 812 vmlinux decode_choice(base =0xFFFFFFD008037280, nivel=0) + 1216 vmlinux DecodeRasMessage() + 304 vmlinux ras_help() + 684 vmlinux nf_confirm() + 188 Debido a datos anormales en skb-&gt;data, la longitud del mapa de bits de la extensión excede 32 cuando se decodifica el mensaje ras y luego usa la longitud para realizar una operación de cambio . Cambiará a negativo después de varios bucles. • https://git.kernel.org/stable/c/5e35941d990123f155b02d5663e51a24f816b6f3 https://git.kernel.org/stable/c/98db42191329c679f4ca52bec0b319689e1ad8cb https://git.kernel.org/stable/c/4bafcc43baf7bcf93566394dbd15726b5b456b7a https://git.kernel.org/stable/c/ccd1108b16ab572d9bf635586b0925635dbd6bbc https://git.kernel.org/stable/c/b3c0f553820516ad4b62a9390ecd28d6f73a7b13 https://git.kernel.org/stable/c/39001e3c42000e7c2038717af0d33c32319ad591 https://git.kernel.org/stable/c/014a807f1cc9c9d5173c1cd935835553b00d211c https://git.kernel.org/stable/c/80ee5054435a11c87c9a4f30f1ff75008 • CWE-20: Improper Input Validation •

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

In the Linux kernel, the following vulnerability has been resolved: netlink: add nla be16/32 types to minlen array BUG: KMSAN: uninit-value in nla_validate_range_unsigned lib/nlattr.c:222 [inline] BUG: KMSAN: uninit-value in nla_validate_int_range lib/nlattr.c:336 [inline] BUG: KMSAN: uninit-value in validate_nla lib/nlattr.c:575 [inline] BUG: KMSAN: uninit-value in __nla_validate_parse+0x2e20/0x45c0 lib/nlattr.c:631 nla_validate_range_unsigned lib/nlattr.c:222 [inline] nla_validate_int_range lib/nlattr.c:336 [inline] validate_nla lib/nlattr.c:575 [inline] ... The message in question matches this policy: [NFTA_TARGET_REV] = NLA_POLICY_MAX(NLA_BE32, 255), but because NLA_BE32 size in minlen array is 0, the validation code will read past the malformed (too small) attribute. Note: Other attributes, e.g. BITFIELD32, SINT, UINT.. are also missing: those likely should be added too. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netlink: agregue tipos nla be16/32 a la matriz minlen ERROR: KMSAN: valor uninit en nla_validate_range_unsigned lib/nlattr.c:222 [en línea] ERROR: KMSAN: valor uninit en nla_validate_int_range lib/nlattr.c:336 [en línea] ERROR: KMSAN: valor uninit en validar_nla lib/nlattr.c:575 [en línea] ERROR: KMSAN: valor uninit en __nla_validate_parse+0x2e20/0x45c0 lib/nlattr.c:631 nla_validate_range_unsigned lib/nlattr.c:222 [en línea] nla_validate_int_range lib/nlattr.c:336 [en línea] validar_nla lib/nlattr.c:575 [en línea] ... El mensaje en cuestión coincide con esta política: [NFTA_TARGET_REV] = NLA_POLICY_MAX( NLA_BE32, 255), pero debido a que el tamaño de NLA_BE32 en la matriz minlen es 0, el código de validación leerá más allá del atributo con formato incorrecto (demasiado pequeño). Nota: También faltan otros atributos, por ejemplo, BITFIELD32, SINT, UINT...: probablemente también deberían agregarse. • https://git.kernel.org/stable/c/ecaf75ffd5f5db320d8b1da0198eef5a5ce64a3f https://git.kernel.org/stable/c/0ac219c4c3ab253f3981f346903458d20bacab32 https://git.kernel.org/stable/c/a2ab028151841cd833cb53eb99427e0cc990112d https://git.kernel.org/stable/c/7a9d14c63b35f89563c5ecbadf918ad64979712d https://git.kernel.org/stable/c/9a0d18853c280f6a0ee99f91619f2442a17a323a •

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

In the Linux kernel, the following vulnerability has been resolved: afs: Fix endless loop in directory parsing If a directory has a block with only ".__afsXXXX" files in it (from uncompleted silly-rename), these .__afsXXXX files are skipped but without advancing the file position in the dir_context. This leads to afs_dir_iterate() repeating the block again and again. Fix this by making the code that skips the .__afsXXXX file also manually advance the file position. The symptoms are a soft lookup: watchdog: BUG: soft lockup - CPU#3 stuck for 52s! • https://git.kernel.org/stable/c/01d15b68f0418382626792ab35b3fa97a1d406ea https://git.kernel.org/stable/c/8499e2f1218ee8d3029360a10001a6374dd135b7 https://git.kernel.org/stable/c/21a2115e0ca0c1b6b1b105fbc761acd9ab93adcd https://git.kernel.org/stable/c/ab49164c60803d5f637fa9643270db9f459d852c https://git.kernel.org/stable/c/a53411e805e02d813b2f2fd2c9d6eaca1d37fb08 https://git.kernel.org/stable/c/fa70c6954aabbfbca1fe39b9b60f82cf2e8cec38 https://git.kernel.org/stable/c/57e9d49c54528c49b8bffe6d99d782ea051ea534 https://git.kernel.org/stable/c/5c78be006ed9cb735ac2abf4fd64f3f4e •

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

In the Linux kernel, the following vulnerability has been resolved: nvme-fc: do not wait in vain when unloading module The module exit path has race between deleting all controllers and freeing 'left over IDs'. To prevent double free a synchronization between nvme_delete_ctrl and ida_destroy has been added by the initial commit. There is some logic around trying to prevent from hanging forever in wait_for_completion, though it does not handling all cases. E.g. blktests is able to reproduce the situation where the module unload hangs forever. If we completely rely on the cleanup code executed from the nvme_delete_ctrl path, all IDs will be freed eventually. This makes calling ida_destroy unnecessary. We only have to ensure that all nvme_delete_ctrl code has been executed before we leave nvme_fc_exit_module. • https://git.kernel.org/stable/c/4f2c95015ec2a1899161be6c0bdaecedd5a7bfb2 https://git.kernel.org/stable/c/0bf567d6d9ffe09e059bbdfb4d07143cef42c75c https://git.kernel.org/stable/c/085195aa90a924c79e35569bcdad860d764a8e17 https://git.kernel.org/stable/c/baa6b7eb8c66486bd64608adc63fe03b30d3c0b9 https://git.kernel.org/stable/c/c0882c366418bf9c19e1ba7f270fe377a9bf5d67 https://git.kernel.org/stable/c/70fbfc47a392b98e5f8dba70c6efc6839205c982 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html https://access.redhat.com/security/cve/CVE-2024 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') CWE-415: Double Free •

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

In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Add TMF to tmr_list handling An abort that is responded to by iSCSI itself is added to tmr_list but does not go to target core. A LUN_RESET that goes through tmr_list takes a refcounter on the abort and waits for completion. However, the abort will be never complete because it was not started in target core. Unable to locate ITT: 0x05000000 on CID: 0 Unable to locate RefTaskTag: 0x05000000 on CID: 0. wait_for_tasks: Stopping tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop wait for tasks: tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop ... INFO: task kworker/0:2:49 blocked for more than 491 seconds. task:kworker/0:2 state:D stack: 0 pid: 49 ppid: 2 flags:0x00000800 Workqueue: events target_tmr_work [target_core_mod] Call Trace: __switch_to+0x2c4/0x470 _schedule+0x314/0x1730 schedule+0x64/0x130 schedule_timeout+0x168/0x430 wait_for_completion+0x140/0x270 target_put_cmd_and_wait+0x64/0xb0 [target_core_mod] core_tmr_lun_reset+0x30/0xa0 [target_core_mod] target_tmr_work+0xc8/0x1b0 [target_core_mod] process_one_work+0x2d4/0x5d0 worker_thread+0x78/0x6c0 To fix this, only add abort to tmr_list if it will be handled by target core. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: target: core: agregar TMF al manejo de tmr_list. Una cancelación a la que responde iSCSI se agrega a tmr_list pero no va al núcleo de destino. • https://git.kernel.org/stable/c/425a571a7e6fc389954cf2564e1edbba3740e171 https://git.kernel.org/stable/c/11f3fe5001ed05721e641f0ecaa7a73b7deb245d https://git.kernel.org/stable/c/168ed59170de1fd7274080fe102216162d6826cf https://git.kernel.org/stable/c/a9849b67b4402a12eb35eadc9306c1ef9847d53d https://git.kernel.org/stable/c/e717bd412001495f17400bfc09f606f1b594ef5a https://git.kernel.org/stable/c/36bc5040c863b44af06094b22f1e50059227b9cb https://git.kernel.org/stable/c/bd508f96b5fef96d8a0ce9cbb211d82bcfc2341f https://git.kernel.org/stable/c/83ab68168a3d990d5ff39ab030ad5754c •