Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext()<br /> <br /> This command:<br /> <br /> $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact<br /> Error: block dev insert failed: -EBUSY.<br /> <br /> fails because user space requests the same block index to be set for<br /> both ingress and egress.<br /> <br /> [ side note, I don&amp;#39;t think it even failed prior to commit 913b47d3424e<br /> ("net/sched: Introduce tc block netdev tracking infra"), because this<br /> is a command from an old set of notes of mine which used to work, but<br /> alas, I did not scientifically bisect this ]<br /> <br /> The problem is not that it fails, but rather, that the second time<br /> around, it fails differently (and irrecoverably):<br /> <br /> $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact<br /> Error: dsa_core: Flow block cb is busy.<br /> <br /> [ another note: the extack is added by me for illustration purposes.<br /> the context of the problem is that clsact_init() obtains the same<br /> &amp;q-&gt;ingress_block pointer as &amp;q-&gt;egress_block, and since we call<br /> tcf_block_get_ext() on both of them, "dev" will be added to the<br /> block-&gt;ports xarray twice, thus failing the operation: once through<br /> the ingress block pointer, and once again through the egress block<br /> pointer. the problem itself is that when xa_insert() fails, we have<br /> emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the<br /> offload never sees a corresponding FLOW_BLOCK_UNBIND. ]<br /> <br /> Even correcting the bad user input, we still cannot recover:<br /> <br /> $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact<br /> Error: dsa_core: Flow block cb is busy.<br /> <br /> Basically the only way to recover is to reboot the system, or unbind and<br /> rebind the net device driver.<br /> <br /> To fix the bug, we need to fill the correct error teardown path which<br /> was missed during code movement, and call tcf_block_offload_unbind()<br /> when xa_insert() fails.<br /> <br /> [ last note, fundamentally I blame the label naming convention in<br /> tcf_block_get_ext() for the bug. The labels should be named after what<br /> they do, not after the error path that jumps to them. This way, it is<br /> obviously wrong that two labels pointing to the same code mean<br /> something is wrong, and checking the code correctness at the goto site<br /> is also easier ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: dapm: fix bounds checker error in dapm_widget_list_create<br /> <br /> The widgets array in the snd_soc_dapm_widget_list has a __counted_by<br /> attribute attached to it, which points to the num_widgets variable. This<br /> attribute is used in bounds checking, and if it is not set before the<br /> array is filled, then the bounds sanitizer will issue a warning or a<br /> kernel panic if CONFIG_UBSAN_TRAP is set.<br /> <br /> This patch sets the size of the widgets list calculated with<br /> list_for_each as the initial value for num_widgets as it is used for<br /> allocating memory for the array. It is updated with the actual number of<br /> added elements after the array is filled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: dts: imx8ulp: correct the flexspi compatible string<br /> <br /> The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has<br /> 32 LUTs, so correct the compatible string here, otherwise will<br /> meet below error:<br /> <br /> [ 1.119072] ------------[ cut here ]------------<br /> [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64<br /> [ 1.133239] Modules linked in:<br /> [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69<br /> [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT)<br /> [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64<br /> [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64<br /> [ 1.168060] sp : ffff80008002b2a0<br /> [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000<br /> [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000<br /> [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0<br /> [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff<br /> [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002<br /> [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00<br /> [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80<br /> [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001<br /> [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6<br /> [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92<br /> [ 1.246267] Call trace:<br /> [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64<br /> [ 1.253031] spi_mem_exec_op+0x3a0/0x430<br /> [ 1.257139] spi_nor_read_id+0x80/0xcc<br /> [ 1.261065] spi_nor_scan+0x1ec/0xf10<br /> [ 1.264901] spi_nor_probe+0x108/0x2fc<br /> [ 1.268828] spi_mem_probe+0x6c/0xbc<br /> [ 1.272574] spi_probe+0x84/0xe4<br /> [ 1.275958] really_probe+0xbc/0x29c<br /> [ 1.279713] __driver_probe_device+0x78/0x12c<br /> [ 1.284277] driver_probe_device+0xd8/0x15c<br /> [ 1.288660] __device_attach_driver+0xb8/0x134<br /> [ 1.293316] bus_for_each_drv+0x88/0xe8<br /> [ 1.297337] __device_attach+0xa0/0x190<br /> [ 1.301353] device_initial_probe+0x14/0x20<br /> [ 1.305734] bus_probe_device+0xac/0xb0<br /> [ 1.309752] device_add+0x5d0/0x790<br /> [ 1.313408] __spi_add_device+0x134/0x204<br /> [ 1.317606] of_register_spi_device+0x3b4/0x590<br /> [ 1.322348] spi_register_controller+0x47c/0x754<br /> [ 1.327181] devm_spi_register_controller+0x4c/0xa4<br /> [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0<br /> [ 1.336307] platform_probe+0x68/0xc4<br /> [ 1.340145] really_probe+0xbc/0x29c<br /> [ 1.343893] __driver_probe_device+0x78/0x12c<br /> [ 1.348457] driver_probe_device+0xd8/0x15c<br /> [ 1.352838] __driver_attach+0x90/0x19c<br /> [ 1.356857] bus_for_each_dev+0x7c/0xdc<br /> [ 1.360877] driver_attach+0x24/0x30<br /> [ 1.364624] bus_add_driver+0xe4/0x208<br /> [ 1.368552] driver_register+0x5c/0x124<br /> [ 1.372573] __platform_driver_register+0x28/0x34<br /> [ 1.377497] nxp_fspi_driver_init+0x1c/0x28<br /> [ 1.381888] do_one_initcall+0x80/0x1c8<br /> [ 1.385908] kernel_init_freeable+0x1c4/0x28c<br /> [ 1.390472] kernel_init+0x20/0x1d8<br /> [ 1.394138] ret_from_fork+0x10/0x20<br /> [ 1.397885] ---[ end trace 0000000000000000 ]---<br /> [ 1.407908] ------------[ cut here ]------------

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()<br /> <br /> There are code paths from which the function is called without holding<br /> the RCU read lock, resulting in a suspicious RCU usage warning [1].<br /> <br /> Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire<br /> the RCU read lock before calling<br /> l3mdev_master_upper_ifindex_by_index_rcu().<br /> <br /> [1]<br /> WARNING: suspicious RCU usage<br /> 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted<br /> -----------------------------<br /> net/core/dev.c:876 RCU-list traversed in non-reader section!!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 1 lock held by ip/361:<br /> #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60<br /> <br /> stack backtrace:<br /> CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141<br /> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xba/0x110<br /> lockdep_rcu_suspicious.cold+0x4f/0xd6<br /> dev_get_by_index_rcu+0x1d3/0x210<br /> l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0<br /> ip_tunnel_bind_dev+0x72f/0xa00<br /> ip_tunnel_newlink+0x368/0x7a0<br /> ipgre_newlink+0x14c/0x170<br /> __rtnl_newlink+0x1173/0x19c0<br /> rtnl_newlink+0x6c/0xa0<br /> rtnetlink_rcv_msg+0x3cc/0xf60<br /> netlink_rcv_skb+0x171/0x450<br /> netlink_unicast+0x539/0x7f0<br /> netlink_sendmsg+0x8c1/0xd80<br /> ____sys_sendmsg+0x8f9/0xc20<br /> ___sys_sendmsg+0x197/0x1e0<br /> __sys_sendmsg+0x122/0x1f0<br /> do_syscall_64+0xbb/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mctp i2c: handle NULL header address<br /> <br /> daddr can be NULL if there is no neighbour table entry present,<br /> in that case the tx packet should be dropped.<br /> <br /> saddr will usually be set by MCTP core, but check for NULL in case a<br /> packet is transmitted by a different protocol.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()<br /> <br /> The per-netns IP tunnel hash table is protected by the RTNL mutex and<br /> ip_tunnel_find() is only called from the control path where the mutex is<br /> taken.<br /> <br /> Add a lockdep expression to hlist_for_each_entry_rcu() in<br /> ip_tunnel_find() in order to validate that the mutex is held and to<br /> silence the suspicious RCU usage warning [1].<br /> <br /> [1]<br /> WARNING: suspicious RCU usage<br /> 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted<br /> -----------------------------<br /> net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 1 lock held by ip/362:<br /> #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60<br /> <br /> stack backtrace:<br /> CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139<br /> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xba/0x110<br /> lockdep_rcu_suspicious.cold+0x4f/0xd6<br /> ip_tunnel_find+0x435/0x4d0<br /> ip_tunnel_newlink+0x517/0x7a0<br /> ipgre_newlink+0x14c/0x170<br /> __rtnl_newlink+0x1173/0x19c0<br /> rtnl_newlink+0x6c/0xa0<br /> rtnetlink_rcv_msg+0x3cc/0xf60<br /> netlink_rcv_skb+0x171/0x450<br /> netlink_unicast+0x539/0x7f0<br /> netlink_sendmsg+0x8c1/0xd80<br /> ____sys_sendmsg+0x8f9/0xc20<br /> ___sys_sendmsg+0x197/0x1e0<br /> __sys_sendmsg+0x122/0x1f0<br /> do_syscall_64+0xbb/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> resource,kexec: walk_system_ram_res_rev must retain resource flags<br /> <br /> walk_system_ram_res_rev() erroneously discards resource flags when passing<br /> the information to the callback.<br /> <br /> This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have<br /> these resources selected during kexec to store kexec buffers if that<br /> memory happens to be at placed above normal system ram.<br /> <br /> This leads to undefined behavior after reboot. If the kexec buffer is<br /> never touched, nothing happens. If the kexec buffer is touched, it could<br /> lead to a crash (like below) or undefined behavior.<br /> <br /> Tested on a system with CXL memory expanders with driver managed memory,<br /> TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk&amp;#39;s showed the flags<br /> were being discarded and as a result the check for<br /> IORESOURCE_SYSRAM_DRIVER_MANAGED passes.<br /> <br /> find_next_iomem_res: name(System RAM (kmem))<br /> start(10000000000)<br /> end(1034fffffff)<br /> flags(83000200)<br /> <br /> locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0)<br /> <br /> [.] BUG: unable to handle page fault for address: ffff89834ffff000<br /> [.] #PF: supervisor read access in kernel mode<br /> [.] #PF: error_code(0x0000) - not-present page<br /> [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0<br /> [.] Oops: 0000 [#1] SMP<br /> [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0<br /> [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286<br /> [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000<br /> [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018<br /> [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900<br /> [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000<br /> [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000<br /> [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000<br /> [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [.] ata5: SATA link down (SStatus 0 SControl 300)<br /> [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0<br /> [.] PKRU: 55555554<br /> [.] Call Trace:<br /> [.] <br /> [.] ? __die+0x78/0xc0<br /> [.] ? page_fault_oops+0x2a8/0x3a0<br /> [.] ? exc_page_fault+0x84/0x130<br /> [.] ? asm_exc_page_fault+0x22/0x30<br /> [.] ? ima_restore_measurement_list+0x95/0x4b0<br /> [.] ? template_desc_init_fields+0x317/0x410<br /> [.] ? crypto_alloc_tfm_node+0x9c/0xc0<br /> [.] ? init_ima_lsm+0x30/0x30<br /> [.] ima_load_kexec_buffer+0x72/0xa0<br /> [.] ima_init+0x44/0xa0<br /> [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0<br /> [.] ? init_ima_lsm+0x30/0x30<br /> [.] do_one_initcall+0xad/0x200<br /> [.] ? idr_alloc_cyclic+0xaa/0x110<br /> [.] ? new_slab+0x12c/0x420<br /> [.] ? new_slab+0x12c/0x420<br /> [.] ? number+0x12a/0x430<br /> [.] ? sysvec_apic_timer_interrupt+0xa/0x80<br /> [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20<br /> [.] ? parse_args+0xd4/0x380<br /> [.] ? parse_args+0x14b/0x380<br /> [.] kernel_init_freeable+0x1c1/0x2b0<br /> [.] ? rest_init+0xb0/0xb0<br /> [.] kernel_init+0x16/0x1a0<br /> [.] ret_from_fork+0x2f/0x40<br /> [.] ? rest_init+0xb0/0xb0<br /> [.] ret_from_fork_asm+0x11/0x20<br /> [.]

A vulnerability was found in Weaver E-cology allows attackers use race conditions to bypass security mechanisms to upload malicious files and control server privileges

An issue in Weaver E-cology v. attackers construct special requests to insert remote malicious code and to trigger malicious code execution, and control server privileges

Weaver Ecology v9.* was discovered to contain a SQL injection vulnerability via the component /mobilemode/Action.jsp?invoker=com.weaver.formmodel.mobile.mec.servlet.MECAction&amp;action=getFieldTriggerValue&amp;searchField=*&amp;fromTable=HrmResourceManager&amp;whereClause=1%3d1&amp;triggerCondition=1&amp;expression=%3d&amp;fieldValue=1.

Qualys discovered that needrestart, before version 3.8, allows local attackers to execute arbitrary code as root by tricking needrestart into running the Python interpreter with an attacker-controlled PYTHONPATH environment variable.

Qualys discovered that needrestart, before version 3.8, allows local attackers to execute arbitrary code as root by winning a race condition and tricking needrestart into running their own, fake Python interpreter (instead of the system&amp;#39;s real Python interpreter). The initial security fix (6ce6136) introduced a regression which was subsequently resolved (42af5d3).