CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35966 – Bluetooth: RFCOMM: Fix not validating setsockopt user input
https://notcve.org/view.php?id=CVE-2024-35966
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix not validating setsockopt user input syzbot reported rfcomm_sock_setsockopt_old() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: RFCOMM: solución al no validar la entrada del usuario de setsockopt. Syzbot informó que rfcomm_sock_setsockopt_old() está copiando datos sin verificar la longitud de la entrada del usuario. BUG: KASAN: slab fuera de los límites en copy_from_sockptr_offset include/linux/sockptr.h:49 [en línea] BUG: KASAN: slab fuera de los límites en copy_from_sockptr include/linux/sockptr.h:55 [en línea] ERROR: KASAN: losa fuera de los límites en rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [en línea] BUG: KASAN: losa fuera de los límites en rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/ sock.c:673 Lectura de tamaño 4 en addr ffff8880209a8bc3 por tarea syz-executor632/5064 • https://git.kernel.org/stable/c/9f2c8a03fbb3048cf38b158f87aa0c3c09bca084 https://git.kernel.org/stable/c/eea40d33bf936a5c7fb03c190e61e0cfee00e872 https://git.kernel.org/stable/c/4ea65e2095e9bd151d0469328dd7fc2858feb546 https://git.kernel.org/stable/c/c3f787a3eafe519c93df9abbb0ca5145861c8d0f https://git.kernel.org/stable/c/a97de7bff13b1cc825c1b1344eaed8d6c2d3e695 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35965 – Bluetooth: L2CAP: Fix not validating setsockopt user input
https://notcve.org/view.php?id=CVE-2024-35965
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix not validating setsockopt user input Check user input length before copying data. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: L2CAP: solución que no valida la entrada del usuario de setsockopt. Verifique la longitud de la entrada del usuario antes de copiar datos. • https://git.kernel.org/stable/c/33575df7be6748292f88453f29319af6d639c5c8 https://git.kernel.org/stable/c/f13b04cf65a86507ff15a9bbf37969d25be3e2a0 https://git.kernel.org/stable/c/9d42f373391211c7c8af66a3a316533a32b8a607 https://git.kernel.org/stable/c/28234f8ab69c522ba447f3e041bbfbb284c5959a https://git.kernel.org/stable/c/8ee0c132a61df9723813c40e742dc5321824daa9 https://git.kernel.org/stable/c/4f3951242ace5efc7131932e2e01e6ac6baed846 •
CVSS: 9.1EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35960 – net/mlx5: Properly link new fs rules into the tree
https://notcve.org/view.php?id=CVE-2024-35960
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Properly link new fs rules into the tree Previously, add_rule_fg would only add newly created rules from the handle into the tree when they had a refcount of 1. On the other hand, create_flow_handle tries hard to find and reference already existing identical rules instead of creating new ones. These two behaviors can result in a situation where create_flow_handle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because del_sw_hw_rule, invoked on rule deletion, assumes node->parent is != NULL. This happened in the wild, due to another bug related to incorrect handling of duplicate pkt_reformat ids, which lead to the code in create_flow_handle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1]. This patch changes add_rule_fg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in create_flow_handle. • https://git.kernel.org/stable/c/74491de937125d0c98c9b9c9208b4105717a3caa https://git.kernel.org/stable/c/de0139719cdda82806a47580ca0df06fc85e0bd2 https://git.kernel.org/stable/c/1263b0b26077b1183c3c45a0a2479573a351d423 https://git.kernel.org/stable/c/3d90ca9145f6b97b38d0c2b6b30f6ca6af9c1801 https://git.kernel.org/stable/c/7aaee12b804c5e0374e7b132b6ec2158ff33dd64 https://git.kernel.org/stable/c/2e8dc5cffc844dacfa79f056dea88002312f253f https://git.kernel.org/stable/c/5cf5337ef701830f173b4eec00a4f984adeb57a0 https://git.kernel.org/stable/c/adf67a03af39095f05d82050f15813d6f • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-35950 – drm/client: Fully protect modes[] with dev->mode_config.mutex
https://notcve.org/view.php?id=CVE-2024-35950
In the Linux kernel, the following vulnerability has been resolved: drm/client: Fully protect modes[] with dev->mode_config.mutex The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/client: Protege completamente los modos[] con dev->mode_config.mutex. La matriz modes[] contiene punteros a los modos en las listas de modos de los conectores, que están protegidos por dev- >mode_config.mutex. Por lo tanto, necesitamos extender modes[] la misma protección o, cuando la usemos, es posible que los elementos ya estén apuntando a la memoria liberada/reutilizada. • https://git.kernel.org/stable/c/5a2f957e3c4553bbb100504a1acfeaeb33f4ca4e https://git.kernel.org/stable/c/41586487769eede64ab1aa6c65c74cbf76c12ef0 https://git.kernel.org/stable/c/d2dc6600d4e3e1453e3b1fb233e9f97e2a1ae949 https://git.kernel.org/stable/c/18c8cc6680ce938d0458859b6a08b4d34f7d8055 https://git.kernel.org/stable/c/04e018bd913d3d3336ab7d21c2ad31a9175fe984 https://git.kernel.org/stable/c/8ceb873d816786a7c8058f50d903574aff8d3764 https://git.kernel.org/stable/c/3eadd887dbac1df8f25f701e5d404d1b90fd0fea https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-35949 – btrfs: make sure that WRITTEN is set on all metadata blocks
https://notcve.org/view.php?id=CVE-2024-35949
In the Linux kernel, the following vulnerability has been resolved: btrfs: make sure that WRITTEN is set on all metadata blocks We previously would call btrfs_check_leaf() if we had the check integrity code enabled, which meant that we could only run the extended leaf checks if we had WRITTEN set on the header flags. This leaves a gap in our checking, because we could end up with corruption on disk where WRITTEN isn't set on the leaf, and then the extended leaf checks don't get run which we rely on to validate all of the item pointers to make sure we don't access memory outside of the extent buffer. However, since 732fab95abe2 ("btrfs: check-integrity: remove CONFIG_BTRFS_FS_CHECK_INTEGRITY option") we no longer call btrfs_check_leaf() from btrfs_mark_buffer_dirty(), which means we only ever call it on blocks that are being written out, and thus have WRITTEN set, or that are being read in, which should have WRITTEN set. Add checks to make sure we have WRITTEN set appropriately, and then make sure __btrfs_check_leaf() always does the item checking. This will protect us from file systems that have been corrupted and no longer have WRITTEN set on some of the blocks. This was hit on a crafted image tweaking the WRITTEN bit and reported by KASAN as out-of-bound access in the eb accessors. The example is a dir item at the end of an eb. [2.042] BTRFS warning (device loop1): bad eb member start: ptr 0x3fff start 30572544 member offset 16410 size 2 [2.040] general protection fault, probably for non-canonical address 0xe0009d1000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI [2.537] KASAN: maybe wild-memory-access in range [0x0005088000000018-0x000508800000001f] [2.729] CPU: 0 PID: 2587 Comm: mount Not tainted 6.8.2 #1 [2.729] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [2.621] RIP: 0010:btrfs_get_16+0x34b/0x6d0 [2.621] RSP: 0018:ffff88810871fab8 EFLAGS: 00000206 [2.621] RAX: 0000a11000000003 RBX: ffff888104ff8720 RCX: ffff88811b2288c0 [2.621] RDX: dffffc0000000000 RSI: ffffffff81dd8aca RDI: ffff88810871f748 [2.621] RBP: 000000000000401a R08: 0000000000000001 R09: ffffed10210e3ee9 [2.621] R10: ffff88810871f74f R11: 205d323430333737 R12: 000000000000001a [2.621] R13: 000508800000001a R14: 1ffff110210e3f5d R15: ffffffff850011e8 [2.621] FS: 00007f56ea275840(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 [2.621] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2.621] CR2: 00007febd13b75c0 CR3: 000000010bb50000 CR4: 00000000000006f0 [2.621] Call Trace: [2.621] <TASK> [2.621] ? show_regs+0x74/0x80 [2.621] ? die_addr+0x46/0xc0 [2.621] ? • https://git.kernel.org/stable/c/ef3ba8ce8cf7075b716aa4afcefc3034215878ee https://git.kernel.org/stable/c/e03418abde871314e1a3a550f4c8afb7b89cb273 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534 •