CVE-2024-26631 – ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work
https://notcve.org/view.php?id=CVE-2024-26631
In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work idev->mc_ifc_count can be written over without proper locking. Originally found by syzbot [1], fix this issue by encapsulating calls to mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with mutex_lock() and mutex_unlock() accordingly as these functions should only be called with mc_lock per their declarations. [1] BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work write to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0: mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline] ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 addrconf_notify+0x310/0x980 notifier_call_chain kernel/notifier.c:93 [inline] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 __dev_notify_flags+0x205/0x3d0 dev_change_flags+0xab/0xd0 net/core/dev.c:8685 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 rtnl_group_changelink net/core/rtnetlink.c:3458 [inline] __rtnl_newlink net/core/rtnetlink.c:3717 [inline] rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910 ... write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1: mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700 worker_thread+0x525/0x730 kernel/workqueue.c:2781 ... En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: mcast: corrige data-race en ipv6_mc_down / mld_ifc_work idev->mc_ifc_count se puede sobrescribir sin el bloqueo adecuado. Originalmente encontrado por syzbot [1], solucione este problema encapsulando las llamadas a mld_ifc_stop_work() (y mld_gq_stop_work() por si acaso) con mutex_lock() y mutex_unlock() en consecuencia, ya que estas funciones solo deben llamarse con mc_lock según sus declaraciones. [1] ERROR: KCSAN: carrera de datos en ipv6_mc_down / mld_ifc_work escribir en 0xffff88813a80c832 de 1 bytes por tarea 3771 en la CPU 0: mld_ifc_stop_work net/ipv6/mcast.c:1080 [en línea] ipv6_mc_down+0x10a/0x280 net/ipv6/mcast .c:2725 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 addrconf_notify+0x310/0x980 notifier_call_chain kernel/notifier.c:93 [en línea] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 __dev_notify_flag s+0x205/ 0x3d0 dev_change_flags+0xab/0xd0 net/core/dev.c:8685 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 rtnl_group_changelink net/core/rtnetlink.c:3458 [en línea] __rtnl_newlink net/core/rtnetlink.c :3717 [en línea] rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 rtnetlink_rcv+0 x1c /0x20 net/core/rtnetlink.c:6576 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [en línea] netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c :1910 ... escriba en 0xffff88813a80c832 de 1 bytes por tarea 22 en la CPU 1: mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 Process_one_work kernel/workqueue.c:2627 [en línea] Process_scheduled_works+0x5b8/0xa30 kernel/ workqueue.c:2700 trabajador_thread+0x525/0x730 kernel/workqueue.c:2781 ... • https://git.kernel.org/stable/c/2d9a93b4902be6a5504b5941dd15e9cd776aadca https://git.kernel.org/stable/c/62b3387beef11738eb6ce667601a28fa089fa02c https://git.kernel.org/stable/c/380540bb06bb1d1b12bdc947d1b8f56cda6b5663 https://git.kernel.org/stable/c/3cc283fd16fba72e2cefe3a6f48d7a36b0438900 https://git.kernel.org/stable/c/3bb5849675ae1d592929798a2b37ea450879c855 https://git.kernel.org/stable/c/2e7ef287f07c74985f1bf2858bedc62bd9ebf155 •
CVE-2023-52613 – drivers/thermal/loongson2_thermal: Fix incorrect PTR_ERR() judgment
https://notcve.org/view.php?id=CVE-2023-52613
In the Linux kernel, the following vulnerability has been resolved: drivers/thermal/loongson2_thermal: Fix incorrect PTR_ERR() judgment PTR_ERR() returns -ENODEV when thermal-zones are undefined, and we need -ENODEV as the right value for comparison. Otherwise, tz->type is NULL when thermal-zones is undefined, resulting in the following error: [ 12.290030] CPU 1 Unable to handle kernel paging request at virtual address fffffffffffffff1, era == 900000000355f410, ra == 90000000031579b8 [ 12.302877] Oops[#1]: [ 12.305190] CPU: 1 PID: 181 Comm: systemd-udevd Not tainted 6.6.0-rc7+ #5385 [ 12.312304] pc 900000000355f410 ra 90000000031579b8 tp 90000001069e8000 sp 90000001069eba10 [ 12.320739] a0 0000000000000000 a1 fffffffffffffff1 a2 0000000000000014 a3 0000000000000001 [ 12.329173] a4 90000001069eb990 a5 0000000000000001 a6 0000000000001001 a7 900000010003431c [ 12.337606] t0 fffffffffffffff1 t1 54567fd5da9b4fd4 t2 900000010614ec40 t3 00000000000dc901 [ 12.346041] t4 0000000000000000 t5 0000000000000004 t6 900000010614ee20 t7 900000000d00b790 [ 12.354472] t8 00000000000dc901 u0 54567fd5da9b4fd4 s9 900000000402ae10 s0 900000010614ec40 [ 12.362916] s1 90000000039fced0 s2 ffffffffffffffed s3 ffffffffffffffed s4 9000000003acc000 [ 12.362931] s5 0000000000000004 s6 fffffffffffff000 s7 0000000000000490 s8 90000001028b2ec8 [ 12.362938] ra: 90000000031579b8 thermal_add_hwmon_sysfs+0x258/0x300 [ 12.386411] ERA: 900000000355f410 strscpy+0xf0/0x160 [ 12.391626] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 12.397898] PRMD: 00000004 (PPLV0 +PIE -PWE) [ 12.403678] EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [ 12.409859] ECFG: 00071c1c (LIE=2-4,10-12 VS=7) [ 12.415882] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 12.415907] BADV: fffffffffffffff1 [ 12.415911] PRID: 0014a000 (Loongson-64bit, Loongson-2K1000) [ 12.415917] Modules linked in: loongson2_thermal(+) vfat fat uio_pdrv_genirq uio fuse zram zsmalloc [ 12.415950] Process systemd-udevd (pid: 181, threadinfo=00000000358b9718, task=00000000ace72fe3) [ 12.415961] Stack : 0000000000000dc0 54567fd5da9b4fd4 900000000402ae10 9000000002df9358 [ 12.415982] ffffffffffffffed 0000000000000004 9000000107a10aa8 90000001002a3410 [ 12.415999] ffffffffffffffed ffffffffffffffed 9000000107a11268 9000000003157ab0 [ 12.416016] 9000000107a10aa8 ffffff80020fc0c8 90000001002a3410 ffffffffffffffed [ 12.416032] 0000000000000024 ffffff80020cc1e8 900000000402b2a0 9000000003acc000 [ 12.416048] 90000001002a3410 0000000000000000 ffffff80020f4030 90000001002a3410 [ 12.416065] 0000000000000000 9000000002df6808 90000001002a3410 0000000000000000 [ 12.416081] ffffff80020f4030 0000000000000000 90000001002a3410 9000000002df2ba8 [ 12.416097] 00000000000000b4 90000001002a34f4 90000001002a3410 0000000000000002 [ 12.416114] ffffff80020f4030 fffffffffffffff0 90000001002a3410 9000000002df2f30 [ 12.416131] ... [ 12.416138] Call Trace: [ 12.416142] [<900000000355f410>] strscpy+0xf0/0x160 [ 12.416167] [<90000000031579b8>] thermal_add_hwmon_sysfs+0x258/0x300 [ 12.416183] [<9000000003157ab0>] devm_thermal_add_hwmon_sysfs+0x50/0xe0 [ 12.416200] [<ffffff80020cc1e8>] loongson2_thermal_probe+0x128/0x200 [loongson2_thermal] [ 12.416232] [<9000000002df6808>] platform_probe+0x68/0x140 [ 12.416249] [<9000000002df2ba8>] really_probe+0xc8/0x3c0 [ 12.416269] [<9000000002df2f30>] __driver_probe_device+0x90/0x180 [ 12.416286] [<9000000002df3058>] driver_probe_device+0x38/0x160 [ 12.416302] [<9000000002df33a8>] __driver_attach+0xa8/0x200 [ 12.416314] [<9000000002deffec>] bus_for_each_dev+0x8c/0x120 [ 12.416330] [<9000000002df198c>] bus_add_driver+0x10c/0x2a0 [ 12.416346] [<9000000002df46b4>] driver_register+0x74/0x160 [ 12.416358] [<90000000022201a4>] do_one_initcall+0x84/0x220 [ 12.416372] [<90000000022f3ab8>] do_init_module+0x58/0x2c0 [ ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drivers/thermal/loongson2_thermal: corrige el juicio PTR_ERR() incorrecto. PTR_ERR() devuelve -ENODEV cuando las zonas térmicas no están definidas y necesitamos -ENODEV como el valor correcto para comparar. De lo contrario, tz->type es NULL cuando las zonas térmicas no están definidas, lo que genera el siguiente error: [12.290030] CPU 1 No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffffffffffffffff1, era == 900000000355f410, ra == 90000000031579b8 [ 12.302877] Ups [#1]: [ 12.305190] CPU: 1 PID: 181 Comm: systemd-udevd No contaminado 6.6.0-rc7+ #5385 [ 12.312304] pc 900000000355f410 ra 90000000031579b8 tp 90000001069e8000 sp 90000001069eba10 [ 12.320739] a0 0000000000000000 a1 ffffffffffffffff1 a2 0000000000000014 a3 0000000000000001 [ 12.329173] a4 90000001069eb990 a5 0000000000000001 a6 0000000000001001 a7 900000010003431c [ 12.337606] t0 ffffffffffffffff1 t1 54567fd5da9b 4fd4 t2 900000010614ec40 t3 00000000000dc901 [ 12.346041] t4 0000000000000000 t5 00000000000000004 t6 900000010614ee20 t7 900000000d00b 790 [ 12.354472] t8 00000000000dc901 u0 54567fd5da9b4fd4 s9 900000000402ae10 s0 900000010614ec40 [ 12.362916] s1 90000000039fced0 s2 ffffffffffffffff s3 ffffffffffffffff s4 9000000003acc000 [ 12.362931] s5 0000000000000004 s6 fffffffffffff000 s7 0000000000000490 s8 90000001028b2ec8 [ 12.362938] ra: 90000000031579b8 Thermal_add_hwmon_sysfs+0x258/0x300 [ 12.386411] ERA: 900000000355f410 strscpy+0xf0/0x160 [ 12.391626] CRMD: 00000 0b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 12.397898] PRMD: 00000004 (PPLV0 +PIE -PWE) [ 12.403678] EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [ 12.409859] ECFG: 00071c1c (LIE=2 -4,10-12 vs = 7) [12.415882] ESTAT: 00010000 [PIL] (IS = ECODE = 1 ESUBCODE = 0) [12.415907] BADV: FFFFFFFFFFFFFF1 [12.415911] PRID: 0014A000 (Loongson-64bit, Loongson-24000) [12.415917] Módulos vinculados en: loongson2_thermal(+) vfat fat uio_pdrv_genirq uio fuse zram zsmalloc [12.415950] Proceso systemd-udevd (pid: 181, threadinfo=00000000358b9718, task=00000000ace72fe3) [ 12.415961] Pila: 0000000000000dc0 54567fd5da9b4fd4 900000000402ae10 9000000002df9358 [12.415982] ffffffffffffff 0000000000000004 9000000107a10aa8 90000001002a3410 [ 12.415999] ffffffffffffff ffffffffffffff 9000000107a11268 9000000003157ab0 [ 12.416016] 9000000107a10aa8 ffffff80020fc0c8 90000001002a3410 ffffffffffffffed [ 12.416032] 00000000000000024 ffffff80020cc1e8 900000000402b2 a0 9000000003acc000 [ 12.416048] 90000001002a3410 0000000000000000 ffffff80020f4030 90000001002a3410 [ 12.416065] 00000000000000000 9000000002df6808 90000001002a3410 0000000000000000 [ 12.416081] ffffff80020f4030 00000000000000000 90000001002a3410 9000000002df2ba 8 [ 12.416097] 00000000000000b4 90000001002a34f4 90000001002a3410 0000000000000002 [ 12.416114] ffffff80020f4030 ffffffffffffff0 90000001002a3410 9000000002df2f30 [ 12 .416131] ... [ 12.416138] Seguimiento de llamadas: [ 12.416142] [<900000000355f410>] strscpy+0xf0/0x160 [ 12.416167] [<90000000031579b8>] Thermal_add_hwmon_sysfs+0x258/0 x300 [12.416183 ] [<9000000003157ab0>] devm_thermal_add_hwmon_sysfs+0x50/0xe0 [ 12.416200] [] loongson2_thermal_probe+0x128/0x200 [loongson2_thermal] [ 12.416232] [<9 000000002df6808>] plataforma_probe+0x68/0x140 [ 12.416249] [<9000000002df2ba8>] realmente_probe+ 0xc8/0x3c0 [ 12.416269] [<9000000002df2f30>] __driver_probe_device+0x90/0x180 [ 12.416286] [<9000000002df3058>] driver_probe_device+0x38/0x160 [ 12.41630 2] [<9000000002df33a8>] __driver_attach+0xa8/0x200 [ 12.416314] [<9000000002deffec>] bus_for_each_dev+0x8c/0x120 [ 12.416330] [<9000000002df198c>] bus_add_driver+0x10c/0x2a0 [ 12.416346] [<9000000002df46b4>] driver_register+0x74/0x160 [ 12.41 6358] [<90000000022201a4>] do_one_initcall+0x84/0x220 [ 12.416372] [<90000000022f3ab8 >] do_init_module+0x58/0x2c0 [ ---truncado--- • https://git.kernel.org/stable/c/e7e3a7c35791fe7a70997883fb8ada5866a40f4d https://git.kernel.org/stable/c/70481755ed77400e783200e2d022e5fea16060ce https://git.kernel.org/stable/c/6010a9fc14eb1feab5cafd84422001134fe8ec58 https://git.kernel.org/stable/c/15ef92e9c41124ee9d88b01208364f3fe1f45f84 •
CVE-2023-52612 – crypto: scomp - fix req->dst buffer overflow
https://notcve.org/view.php?id=CVE-2023-52612
In the Linux kernel, the following vulnerability has been resolved: crypto: scomp - fix req->dst buffer overflow The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid req->dst buffer overflow problem. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: scomp - corrige el desbordamiento del búfer req->dst. El tamaño del búfer req->dst debe verificarse antes de copiar desde scomp_scratch->dst para evitar el problema de desbordamiento del búfer req->dst. . • https://git.kernel.org/stable/c/1ab53a77b772bf7369464a0e4fa6fd6499acf8f1 https://git.kernel.org/stable/c/1142d65c5b881590962ad763f94505b6dd67d2fe https://git.kernel.org/stable/c/e0e3f4a18784182cfe34e20c00eca11e78d53e76 https://git.kernel.org/stable/c/4518dc468cdd796757190515a9be7408adc8911e https://git.kernel.org/stable/c/a5f2f91b3fd7387e5102060809316a0f8f0bc625 https://git.kernel.org/stable/c/4df0c942d04a67df174195ad8082f6e30e7f71a5 https://git.kernel.org/stable/c/7d9e5bed036a7f9e2062a137e97e3c1e77fb8759 https://git.kernel.org/stable/c/71c6670f9f032ec67d8f4e3f8db4646bf •
CVE-2023-52611 – wifi: rtw88: sdio: Honor the host max_req_size in the RX path
https://notcve.org/view.php?id=CVE-2023-52611
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: sdio: Honor the host max_req_size in the RX path Lukas reports skb_over_panic errors on his Banana Pi BPI-CM4 which comes with an Amlogic A311D (G12B) SoC and a RTL8822CS SDIO wifi/Bluetooth combo card. The error he observed is identical to what has been fixed in commit e967229ead0e ("wifi: rtw88: sdio: Check the HISR RX_REQUEST bit in rtw_sdio_rx_isr()") but that commit didn't fix Lukas' problem. Lukas found that disabling or limiting RX aggregation works around the problem for some time (but does not fully fix it). In the following discussion a few key topics have been discussed which have an impact on this problem: - The Amlogic A311D (G12B) SoC has a hardware bug in the SDIO controller which prevents DMA transfers. Instead all transfers need to go through the controller SRAM which limits transfers to 1536 bytes - rtw88 chips don't split incoming (RX) packets, so if a big packet is received this is forwarded to the host in it's original form - rtw88 chips can do RX aggregation, meaning more multiple incoming packets can be pulled by the host from the card with one MMC/SDIO transfer. This Depends on settings in the REG_RXDMA_AGG_PG_TH register (BIT_RXDMA_AGG_PG_TH limits the number of packets that will be aggregated, BIT_DMA_AGG_TO_V1 configures a timeout for aggregation and BIT_EN_PRE_CALC makes the chip honor the limits more effectively) Use multiple consecutive reads in rtw_sdio_read_port() and limit the number of bytes which are copied by the host from the card in one MMC/SDIO transfer. • https://git.kernel.org/stable/c/65371a3f14e73979958aea0db1e3bb456a296149 https://git.kernel.org/stable/c/5b5ddf21b978ec315cab9d9e7e6ac7374791a8c7 https://git.kernel.org/stable/c/0e9ffff72a0674cd6656314dbd99cdd2123a3030 https://git.kernel.org/stable/c/00384f565a91c08c4bedae167f749b093d10e3fe •
CVE-2023-52610 – net/sched: act_ct: fix skb leak and crash on ooo frags
https://notcve.org/view.php?id=CVE-2023-52610
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: fix skb leak and crash on ooo frags act_ct adds skb->users before defragmentation. If frags arrive in order, the last frag's reference is reset in: inet_frag_reasm_prepare skb_morph which is not straightforward. However when frags arrive out of order, nobody unref the last frag, and all frags are leaked. The situation is even worse, as initiating packet capture can lead to a crash[0] when skb has been cloned and shared at the same time. Fix the issue by removing skb_get() before defragmentation. act_ct returns TC_ACT_CONSUMED when defrag failed or in progress. [0]: [ 843.804823] ------------[ cut here ]------------ [ 843.809659] kernel BUG at net/core/skbuff.c:2091! [ 843.814516] invalid opcode: 0000 [#1] PREEMPT SMP [ 843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2 [ 843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022 [ 843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300 [ 843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89 [ 843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202 [ 843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820 [ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00 [ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000 [ 843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880 [ 843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900 [ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000 [ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0 [ 843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 843.894229] PKRU: 55555554 [ 843.898539] Call Trace: [ 843.902772] <IRQ> [ 843.906922] ? __die_body+0x1e/0x60 [ 843.911032] ? • https://git.kernel.org/stable/c/b57dc7c13ea90e09ae15f821d2583fa0231b4935 https://git.kernel.org/stable/c/172ba7d46c202e679f3ccb10264c67416aaeb1c4 https://git.kernel.org/stable/c/0b5b831122fc3789fff75be433ba3e4dd7b779d4 https://git.kernel.org/stable/c/73f7da5fd124f2cda9161e2e46114915e6e82e97 https://git.kernel.org/stable/c/f5346df0591d10bc948761ca854b1fae6d2ef441 https://git.kernel.org/stable/c/3f14b377d01d8357eba032b4cabc8c1149b458b6 https://access.redhat.com/security/cve/CVE-2023-52610 https://bugzilla.redhat.com/show_bug.cgi?id=2270080 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •