Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: sdio: Honor the host max_req_size in the RX path<br /> <br /> Lukas reports skb_over_panic errors on his Banana Pi BPI-CM4 which comes<br /> with an Amlogic A311D (G12B) SoC and a RTL8822CS SDIO wifi/Bluetooth<br /> combo card. The error he observed is identical to what has been fixed<br /> in commit e967229ead0e ("wifi: rtw88: sdio: Check the HISR RX_REQUEST<br /> bit in rtw_sdio_rx_isr()") but that commit didn&amp;#39;t fix Lukas&amp;#39; problem.<br /> <br /> Lukas found that disabling or limiting RX aggregation works around the<br /> problem for some time (but does not fully fix it). In the following<br /> discussion a few key topics have been discussed which have an impact on<br /> this problem:<br /> - The Amlogic A311D (G12B) SoC has a hardware bug in the SDIO controller<br /> which prevents DMA transfers. Instead all transfers need to go through<br /> the controller SRAM which limits transfers to 1536 bytes<br /> - rtw88 chips don&amp;#39;t split incoming (RX) packets, so if a big packet is<br /> received this is forwarded to the host in it&amp;#39;s original form<br /> - rtw88 chips can do RX aggregation, meaning more multiple incoming<br /> packets can be pulled by the host from the card with one MMC/SDIO<br /> transfer. This Depends on settings in the REG_RXDMA_AGG_PG_TH<br /> register (BIT_RXDMA_AGG_PG_TH limits the number of packets that will<br /> be aggregated, BIT_DMA_AGG_TO_V1 configures a timeout for aggregation<br /> and BIT_EN_PRE_CALC makes the chip honor the limits more effectively)<br /> <br /> Use multiple consecutive reads in rtw_sdio_read_port() and limit the<br /> number of bytes which are copied by the host from the card in one<br /> MMC/SDIO transfer. This allows receiving a buffer that&amp;#39;s larger than<br /> the hosts max_req_size (number of bytes which can be transferred in<br /> one MMC/SDIO transfer). As a result of this the skb_over_panic error<br /> is gone as the rtw88 driver is now able to receive more than 1536 bytes<br /> from the card (either because the incoming packet is larger than that<br /> or because multiple packets have been aggregated).<br /> <br /> In case of an receive errors (-EILSEQ has been observed by Lukas) we<br /> need to drain the remaining data from the card&amp;#39;s buffer, otherwise the<br /> card will return corrupt data for the next rtw_sdio_read_port() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: scomp - fix req-&gt;dst buffer overflow<br /> <br /> The req-&gt;dst buffer size should be checked before copying from the<br /> scomp_scratch-&gt;dst to avoid req-&gt;dst buffer overflow problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers/thermal/loongson2_thermal: Fix incorrect PTR_ERR() judgment<br /> <br /> PTR_ERR() returns -ENODEV when thermal-zones are undefined, and we need<br /> -ENODEV as the right value for comparison.<br /> <br /> Otherwise, tz-&gt;type is NULL when thermal-zones is undefined, resulting<br /> in the following error:<br /> <br /> [ 12.290030] CPU 1 Unable to handle kernel paging request at virtual address fffffffffffffff1, era == 900000000355f410, ra == 90000000031579b8<br /> [ 12.302877] Oops[#1]:<br /> [ 12.305190] CPU: 1 PID: 181 Comm: systemd-udevd Not tainted 6.6.0-rc7+ #5385<br /> [ 12.312304] pc 900000000355f410 ra 90000000031579b8 tp 90000001069e8000 sp 90000001069eba10<br /> [ 12.320739] a0 0000000000000000 a1 fffffffffffffff1 a2 0000000000000014 a3 0000000000000001<br /> [ 12.329173] a4 90000001069eb990 a5 0000000000000001 a6 0000000000001001 a7 900000010003431c<br /> [ 12.337606] t0 fffffffffffffff1 t1 54567fd5da9b4fd4 t2 900000010614ec40 t3 00000000000dc901<br /> [ 12.346041] t4 0000000000000000 t5 0000000000000004 t6 900000010614ee20 t7 900000000d00b790<br /> [ 12.354472] t8 00000000000dc901 u0 54567fd5da9b4fd4 s9 900000000402ae10 s0 900000010614ec40<br /> [ 12.362916] s1 90000000039fced0 s2 ffffffffffffffed s3 ffffffffffffffed s4 9000000003acc000<br /> [ 12.362931] s5 0000000000000004 s6 fffffffffffff000 s7 0000000000000490 s8 90000001028b2ec8<br /> [ 12.362938] ra: 90000000031579b8 thermal_add_hwmon_sysfs+0x258/0x300<br /> [ 12.386411] ERA: 900000000355f410 strscpy+0xf0/0x160<br /> [ 12.391626] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)<br /> [ 12.397898] PRMD: 00000004 (PPLV0 +PIE -PWE)<br /> [ 12.403678] EUEN: 00000000 (-FPE -SXE -ASXE -BTE)<br /> [ 12.409859] ECFG: 00071c1c (LIE=2-4,10-12 VS=7)<br /> [ 12.415882] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)<br /> [ 12.415907] BADV: fffffffffffffff1<br /> [ 12.415911] PRID: 0014a000 (Loongson-64bit, Loongson-2K1000)<br /> [ 12.415917] Modules linked in: loongson2_thermal(+) vfat fat uio_pdrv_genirq uio fuse zram zsmalloc<br /> [ 12.415950] Process systemd-udevd (pid: 181, threadinfo=00000000358b9718, task=00000000ace72fe3)<br /> [ 12.415961] Stack : 0000000000000dc0 54567fd5da9b4fd4 900000000402ae10 9000000002df9358<br /> [ 12.415982] ffffffffffffffed 0000000000000004 9000000107a10aa8 90000001002a3410<br /> [ 12.415999] ffffffffffffffed ffffffffffffffed 9000000107a11268 9000000003157ab0<br /> [ 12.416016] 9000000107a10aa8 ffffff80020fc0c8 90000001002a3410 ffffffffffffffed<br /> [ 12.416032] 0000000000000024 ffffff80020cc1e8 900000000402b2a0 9000000003acc000<br /> [ 12.416048] 90000001002a3410 0000000000000000 ffffff80020f4030 90000001002a3410<br /> [ 12.416065] 0000000000000000 9000000002df6808 90000001002a3410 0000000000000000<br /> [ 12.416081] ffffff80020f4030 0000000000000000 90000001002a3410 9000000002df2ba8<br /> [ 12.416097] 00000000000000b4 90000001002a34f4 90000001002a3410 0000000000000002<br /> [ 12.416114] ffffff80020f4030 fffffffffffffff0 90000001002a3410 9000000002df2f30<br /> [ 12.416131] ...<br /> [ 12.416138] Call Trace:<br /> [ 12.416142] [] strscpy+0xf0/0x160<br /> [ 12.416167] [] thermal_add_hwmon_sysfs+0x258/0x300<br /> [ 12.416183] [] devm_thermal_add_hwmon_sysfs+0x50/0xe0<br /> [ 12.416200] [] loongson2_thermal_probe+0x128/0x200 [loongson2_thermal]<br /> [ 12.416232] [] platform_probe+0x68/0x140<br /> [ 12.416249] [] really_probe+0xc8/0x3c0<br /> [ 12.416269] [] __driver_probe_device+0x90/0x180<br /> [ 12.416286] [] driver_probe_device+0x38/0x160<br /> [ 12.416302] [] __driver_attach+0xa8/0x200<br /> [ 12.416314] [] bus_for_each_dev+0x8c/0x120<br /> [ 12.416330] [] bus_add_driver+0x10c/0x2a0<br /> [ 12.416346] [] driver_register+0x74/0x160<br /> [ 12.416358] [] do_one_initcall+0x84/0x220<br /> [ 12.416372] [] do_init_module+0x58/0x2c0<br /> [<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM / devfreq: Fix buffer overflow in trans_stat_show<br /> <br /> Fix buffer overflow in trans_stat_show().<br /> <br /> Convert simple snprintf to the more secure scnprintf with size of<br /> PAGE_SIZE.<br /> <br /> Add condition checking if we are exceeding PAGE_SIZE and exit early from<br /> loop. Also add at the end a warning that we exceeded PAGE_SIZE and that<br /> stats is disabled.<br /> <br /> Return -EFBIG in the case where we don&amp;#39;t have enough space to write the<br /> full transition table.<br /> <br /> Also document in the ABI that this function can return -EFBIG error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwrng: core - Fix page fault dead lock on mmap-ed hwrng<br /> <br /> There is a dead-lock in the hwrng device read path. This triggers<br /> when the user reads from /dev/hwrng into memory also mmap-ed from<br /> /dev/hwrng. The resulting page fault triggers a recursive read<br /> which then dead-locks.<br /> <br /> Fix this by using a stack buffer when calling copy_to_user.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init<br /> <br /> When the mpi_ec_ctx structure is initialized, some fields are not<br /> cleared, causing a crash when referencing the field when the<br /> structure was released. Initially, this issue was ignored because<br /> memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.<br /> For example, this error will be triggered when calculating the<br /> Za value for SM2 separately.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix race between mmput() and do_exit()<br /> <br /> Task A calls binder_update_page_range() to allocate and insert pages on<br /> a remote address space from Task B. For this, Task A pins the remote mm<br /> via mmget_not_zero() first. This can race with Task B do_exit() and the<br /> final mmput() refcount decrement will come from Task A.<br /> <br /> Task A | Task B<br /> ------------------+------------------<br /> mmget_not_zero() |<br /> | do_exit()<br /> | exit_mm()<br /> | mmput()<br /> mmput() |<br /> exit_mmap() |<br /> remove_vma() |<br /> fput() |<br /> <br /> In this case, the work of ____fput() from Task B is queued up in Task A<br /> as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup<br /> work gets executed. However, Task A instead sleep, waiting for a reply<br /> from Task B that never comes (it&amp;#39;s dead).<br /> <br /> This means the binder_deferred_release() is blocked until an unrelated<br /> binder event forces Task A to go back to userspace. All the associated<br /> death notifications will also be delayed until then.<br /> <br /> In order to fix this use mmput_async() that will schedule the work in<br /> the corresponding mm-&gt;async_put_work WQ instead of Task A.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_ct: fix skb leak and crash on ooo frags<br /> <br /> act_ct adds skb-&gt;users before defragmentation. If frags arrive in order,<br /> the last frag&amp;#39;s reference is reset in:<br /> <br /> inet_frag_reasm_prepare<br /> skb_morph<br /> <br /> which is not straightforward.<br /> <br /> However when frags arrive out of order, nobody unref the last frag, and<br /> all frags are leaked. The situation is even worse, as initiating packet<br /> capture can lead to a crash[0] when skb has been cloned and shared at the<br /> same time.<br /> <br /> Fix the issue by removing skb_get() before defragmentation. act_ct<br /> returns TC_ACT_CONSUMED when defrag failed or in progress.<br /> <br /> [0]:<br /> [ 843.804823] ------------[ cut here ]------------<br /> [ 843.809659] kernel BUG at net/core/skbuff.c:2091!<br /> [ 843.814516] invalid opcode: 0000 [#1] PREEMPT SMP<br /> [ 843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2<br /> [ 843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022<br /> [ 843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300<br /> [ 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 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89<br /> [ 843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202<br /> [ 843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820<br /> [ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00<br /> [ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000<br /> [ 843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880<br /> [ 843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900<br /> [ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000<br /> [ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0<br /> [ 843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 843.894229] PKRU: 55555554<br /> [ 843.898539] Call Trace:<br /> [ 843.902772] <br /> [ 843.906922] ? __die_body+0x1e/0x60<br /> [ 843.911032] ? die+0x3c/0x60<br /> [ 843.915037] ? do_trap+0xe2/0x110<br /> [ 843.918911] ? pskb_expand_head+0x2ac/0x300<br /> [ 843.922687] ? do_error_trap+0x65/0x80<br /> [ 843.926342] ? pskb_expand_head+0x2ac/0x300<br /> [ 843.929905] ? exc_invalid_op+0x50/0x60<br /> [ 843.933398] ? pskb_expand_head+0x2ac/0x300<br /> [ 843.936835] ? asm_exc_invalid_op+0x1a/0x20<br /> [ 843.940226] ? pskb_expand_head+0x2ac/0x300<br /> [ 843.943580] inet_frag_reasm_prepare+0xd1/0x240<br /> [ 843.946904] ip_defrag+0x5d4/0x870<br /> [ 843.950132] nf_ct_handle_fragments+0xec/0x130 [nf_conntrack]<br /> [ 843.953334] tcf_ct_act+0x252/0xd90 [act_ct]<br /> [ 843.956473] ? tcf_mirred_act+0x516/0x5a0 [act_mirred]<br /> [ 843.959657] tcf_action_exec+0xa1/0x160<br /> [ 843.962823] fl_classify+0x1db/0x1f0 [cls_flower]<br /> [ 843.966010] ? skb_clone+0x53/0xc0<br /> [ 843.969173] tcf_classify+0x24d/0x420<br /> [ 843.972333] tc_run+0x8f/0xf0<br /> [ 843.975465] __netif_receive_skb_core+0x67a/0x1080<br /> [ 843.978634] ? dev_gro_receive+0x249/0x730<br /> [ 843.981759] __netif_receive_skb_list_core+0x12d/0x260<br /> [ 843.984869] netif_receive_skb_list_internal+0x1cb/0x2f0<br /> [ 843.987957] ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core]<br /> [ 843.991170] napi_complete_done+0x72/0x1a0<br /> [ 843.994305] mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core]<br /> [ 843.997501] __napi_poll+0x25/0x1b0<br /> [ 844.000627] net_rx_action+0x256/0x330<br /> [ 844.003705] __do_softirq+0xb3/0x29b<br /> [ 844.006718] irq_exit_rcu+0x9e/0xc0<br /> [ 844.009672] common_interrupt+0x86/0xa0<br /> [ 844.012537] <br /> [ 844.015285] <br /> [ 844.017937] asm_common_interrupt+0x26/0x40<br /> [ 844.020591] RIP: 0010:acpi_safe_halt+0x1b/0x20<br /> [ 844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb<br /> ---truncated---

BMC Control-M branches 9.0.20 and 9.0.21 upon user login load all Dynamic Link Libraries (DLL) from a directory that grants Write and Read permissions to all users. Leveraging it leads to loading of a potentially malicious libraries, which will execute with the application&amp;#39;s privileges. <br /> <br /> <br /> <br /> <br /> <br /> Fix for 9.0.20 branch was released in version 9.0.20.238. Fix for 9.0.21 branch was released in version 9.0.21.201.

Lack of input sanitization in BMC Control-M branches 9.0.20 and 9.0.21 allows logged-in users for manipulation of generated web pages via injection of HTML code. This might lead to a successful phishing attack for example by tricking users into using a hyperlink pointing to a website controlled by an attacker.<br /> <br /> Fix for 9.0.20 branch was released in version 9.0.20.238. Fix for 9.0.21 branch was released in version 9.0.21.200. <br /> <br />

Improper authorization in the report management and creation module of BMC Control-M branches 9.0.20 and 9.0.21 allows logged-in users to read and make unauthorized changes to any reports available within the application, even without proper permissions. The attacker must know the unique identifier of the report they want to manipulate.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Fix for 9.0.20 branch was released in version 9.0.20.238. Fix for 9.0.21 branch was released in version 9.0.21.201.

Improper restriction of XML external entity references vulnerability exists in FitNesse all releases, which allows a remote unauthenticated attacker to obtain sensitive information, alter data, or cause a denial-of-service (DoS) condition.