Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bcmgenet: Use stronger register read/writes to assure ordering<br /> <br /> GCC12 appears to be much smarter about its dependency tracking and is<br /> aware that the relaxed variants are just normal loads and stores and<br /> this is causing problems like:<br /> <br /> [ 210.074549] ------------[ cut here ]------------<br /> [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet): transmit queue 1 timed out<br /> [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240<br /> [ 210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat]<br /> [ 210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110<br /> [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 5.17.0-rc7G12+ #58<br /> [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters<br /> [ 210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022<br /> [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 210.161358] pc : dev_watchdog+0x234/0x240<br /> [ 210.161364] lr : dev_watchdog+0x234/0x240<br /> [ 210.161368] sp : ffff8000080a3a40<br /> [ 210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20<br /> [ 210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08<br /> [ 210.212321] x23: 0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000<br /> [ 210.219491] x20: 0000000000000001 x19: ffff55b1426884c8 x18: ffffffffffffffff<br /> [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a<br /> [ 210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0<br /> [ 210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c<br /> [ 210.248171] x8 : 00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000<br /> [ 210.255341] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000001000<br /> [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 : 0000000000000044<br /> [ 210.269682] Call trace:<br /> [ 210.272133] dev_watchdog+0x234/0x240<br /> [ 210.275811] call_timer_fn+0x3c/0x15c<br /> [ 210.279489] __run_timers.part.0+0x288/0x310<br /> [ 210.283777] run_timer_softirq+0x48/0x80<br /> [ 210.287716] __do_softirq+0x128/0x360<br /> [ 210.291392] __irq_exit_rcu+0x138/0x140<br /> [ 210.295243] irq_exit_rcu+0x1c/0x30<br /> [ 210.298745] el1_interrupt+0x38/0x54<br /> [ 210.302334] el1h_64_irq_handler+0x18/0x24<br /> [ 210.306445] el1h_64_irq+0x7c/0x80<br /> [ 210.309857] arch_cpu_idle+0x18/0x2c<br /> [ 210.313445] default_idle_call+0x4c/0x140<br /> [ 210.317470] cpuidle_idle_call+0x14c/0x1a0<br /> [ 210.321584] do_idle+0xb0/0x100<br /> [ 210.324737] cpu_startup_entry+0x30/0x8c<br /> [ 210.328675] secondary_start_kernel+0xe4/0x110<br /> [ 210.333138] __secondary_switched+0x94/0x98<br /> <br /> The assumption when these were relaxed seems to be that device memory<br /> would be mapped non reordering, and that other constructs<br /> (spinlocks/etc) would provide the barriers to assure that packet data<br /> and in memory rings/queues were ordered with respect to device<br /> register reads/writes. This itself seems a bit sketchy, but the real<br /> problem with GCC12 is that it is moving the actual reads/writes around<br /> at will as though they were independent operations when in truth they<br /> are not, but the compiler can&amp;#39;t know that. When looking at the<br /> assembly dumps for many of these routines its possible to see very<br /> clean, but not strictly in program order operations occurring as the<br /> compiler would be free to do if these weren&amp;#39;t actually register<br /> reads/write operations.<br /> <br /> Its possible to suppress the timeout with a liberal bit of dma_mb()&amp;#39;s<br /> sprinkled around but the device still seems unable to reliably<br /> send/receive data. A better plan is to use the safer readl/writel<br /> everywhere.<br /> <br /> Since this partially reverts an older commit, which notes the use of<br /> the relaxed variants for performance reasons. I would suggest that<br /> any performance problems <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block, bfq: don&amp;#39;t move oom_bfqq<br /> <br /> Our test report a UAF:<br /> <br /> [ 2073.019181] ==================================================================<br /> [ 2073.019188] BUG: KASAN: use-after-free in __bfq_put_async_bfqq+0xa0/0x168<br /> [ 2073.019191] Write of size 8 at addr ffff8000ccf64128 by task rmmod/72584<br /> [ 2073.019192]<br /> [ 2073.019196] CPU: 0 PID: 72584 Comm: rmmod Kdump: loaded Not tainted 4.19.90-yk #5<br /> [ 2073.019198] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015<br /> [ 2073.019200] Call trace:<br /> [ 2073.019203] dump_backtrace+0x0/0x310<br /> [ 2073.019206] show_stack+0x28/0x38<br /> [ 2073.019210] dump_stack+0xec/0x15c<br /> [ 2073.019216] print_address_description+0x68/0x2d0<br /> [ 2073.019220] kasan_report+0x238/0x2f0<br /> [ 2073.019224] __asan_store8+0x88/0xb0<br /> [ 2073.019229] __bfq_put_async_bfqq+0xa0/0x168<br /> [ 2073.019233] bfq_put_async_queues+0xbc/0x208<br /> [ 2073.019236] bfq_pd_offline+0x178/0x238<br /> [ 2073.019240] blkcg_deactivate_policy+0x1f0/0x420<br /> [ 2073.019244] bfq_exit_queue+0x128/0x178<br /> [ 2073.019249] blk_mq_exit_sched+0x12c/0x160<br /> [ 2073.019252] elevator_exit+0xc8/0xd0<br /> [ 2073.019256] blk_exit_queue+0x50/0x88<br /> [ 2073.019259] blk_cleanup_queue+0x228/0x3d8<br /> [ 2073.019267] null_del_dev+0xfc/0x1e0 [null_blk]<br /> [ 2073.019274] null_exit+0x90/0x114 [null_blk]<br /> [ 2073.019278] __arm64_sys_delete_module+0x358/0x5a0<br /> [ 2073.019282] el0_svc_common+0xc8/0x320<br /> [ 2073.019287] el0_svc_handler+0xf8/0x160<br /> [ 2073.019290] el0_svc+0x10/0x218<br /> [ 2073.019291]<br /> [ 2073.019294] Allocated by task 14163:<br /> [ 2073.019301] kasan_kmalloc+0xe0/0x190<br /> [ 2073.019305] kmem_cache_alloc_node_trace+0x1cc/0x418<br /> [ 2073.019308] bfq_pd_alloc+0x54/0x118<br /> [ 2073.019313] blkcg_activate_policy+0x250/0x460<br /> [ 2073.019317] bfq_create_group_hierarchy+0x38/0x110<br /> [ 2073.019321] bfq_init_queue+0x6d0/0x948<br /> [ 2073.019325] blk_mq_init_sched+0x1d8/0x390<br /> [ 2073.019330] elevator_switch_mq+0x88/0x170<br /> [ 2073.019334] elevator_switch+0x140/0x270<br /> [ 2073.019338] elv_iosched_store+0x1a4/0x2a0<br /> [ 2073.019342] queue_attr_store+0x90/0xe0<br /> [ 2073.019348] sysfs_kf_write+0xa8/0xe8<br /> [ 2073.019351] kernfs_fop_write+0x1f8/0x378<br /> [ 2073.019359] __vfs_write+0xe0/0x360<br /> [ 2073.019363] vfs_write+0xf0/0x270<br /> [ 2073.019367] ksys_write+0xdc/0x1b8<br /> [ 2073.019371] __arm64_sys_write+0x50/0x60<br /> [ 2073.019375] el0_svc_common+0xc8/0x320<br /> [ 2073.019380] el0_svc_handler+0xf8/0x160<br /> [ 2073.019383] el0_svc+0x10/0x218<br /> [ 2073.019385]<br /> [ 2073.019387] Freed by task 72584:<br /> [ 2073.019391] __kasan_slab_free+0x120/0x228<br /> [ 2073.019394] kasan_slab_free+0x10/0x18<br /> [ 2073.019397] kfree+0x94/0x368<br /> [ 2073.019400] bfqg_put+0x64/0xb0<br /> [ 2073.019404] bfqg_and_blkg_put+0x90/0xb0<br /> [ 2073.019408] bfq_put_queue+0x220/0x228<br /> [ 2073.019413] __bfq_put_async_bfqq+0x98/0x168<br /> [ 2073.019416] bfq_put_async_queues+0xbc/0x208<br /> [ 2073.019420] bfq_pd_offline+0x178/0x238<br /> [ 2073.019424] blkcg_deactivate_policy+0x1f0/0x420<br /> [ 2073.019429] bfq_exit_queue+0x128/0x178<br /> [ 2073.019433] blk_mq_exit_sched+0x12c/0x160<br /> [ 2073.019437] elevator_exit+0xc8/0xd0<br /> [ 2073.019440] blk_exit_queue+0x50/0x88<br /> [ 2073.019443] blk_cleanup_queue+0x228/0x3d8<br /> [ 2073.019451] null_del_dev+0xfc/0x1e0 [null_blk]<br /> [ 2073.019459] null_exit+0x90/0x114 [null_blk]<br /> [ 2073.019462] __arm64_sys_delete_module+0x358/0x5a0<br /> [ 2073.019467] el0_svc_common+0xc8/0x320<br /> [ 2073.019471] el0_svc_handler+0xf8/0x160<br /> [ 2073.019474] el0_svc+0x10/0x218<br /> [ 2073.019475]<br /> [ 2073.019479] The buggy address belongs to the object at ffff8000ccf63f00<br /> which belongs to the cache kmalloc-1024 of size 1024<br /> [ 2073.019484] The buggy address is located 552 bytes inside of<br /> 1024-byte region [ffff8000ccf63f00, ffff8000ccf64300)<br /> [ 2073.019486] The buggy address belongs to the page:<br /> [ 2073.019492] page:ffff7e000333d800 count:1 mapcount:0 mapping:ffff8000c0003a00 index:0x0 compound_mapcount: 0<br /> [ 2073.020123] flags: 0x7ffff0000008100(slab|head)<br /> [ 2073.020403] raw: 07ffff0000008100 ffff7e0003334c08 ffff7e00001f5a08 ffff8000c0003a00<br /> [ 2073.020409] ra<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LSM: general protection fault in legacy_parse_param<br /> <br /> The usual LSM hook "bail on fail" scheme doesn&amp;#39;t work for cases where<br /> a security module may return an error code indicating that it does not<br /> recognize an input. In this particular case Smack sees a mount option<br /> that it recognizes, and returns 0. A call to a BPF hook follows, which<br /> returns -ENOPARAM, which confuses the caller because Smack has processed<br /> its data.<br /> <br /> The SELinux hook incorrectly returns 1 on success. There was a time<br /> when this was correct, however the current expectation is that it<br /> return 0 on success. This is repaired.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: add vlan list lock to protect vlan list<br /> <br /> When adding port base VLAN, vf VLAN need to remove from HW and modify<br /> the vlan state in vf VLAN list as false. If the periodicity task is<br /> freeing the same node, it may cause "use after free" error.<br /> This patch adds a vlan list lock to protect the vlan list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sparx5: switchdev: fix possible NULL pointer dereference<br /> <br /> As the possible failure of the allocation, devm_kzalloc() may return NULL<br /> pointer.<br /> Therefore, it should be better to check the &amp;#39;db&amp;#39; in order to prevent<br /> the dereference of NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: nomadik: Add missing of_node_put() in nmk_pinctrl_probe<br /> <br /> This node pointer is returned by of_parse_phandle() with refcount<br /> incremented in this function. Calling of_node_put() to avoid<br /> the refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: visconti: prevent array overflow in visconti_clk_register_gates()<br /> <br /> This code was using -1 to represent that there was no reset function.<br /> Unfortunately, the -1 was stored in u8 so the if (clks[i].rs_id &gt;= 0)<br /> condition was always true. This lead to an out of bounds access in<br /> visconti_clk_register_gates().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: Fix clk_hw_get_clk() when dev is NULL<br /> <br /> Any registered clk_core structure can have a NULL pointer in its dev<br /> field. While never actually documented, this is evidenced by the wide<br /> usage of clk_register and clk_hw_register with a NULL device pointer,<br /> and the fact that the core of_clk_hw_register() function also passes a<br /> NULL device pointer.<br /> <br /> A call to clk_hw_get_clk() on a clk_hw struct whose clk_core is in that<br /> case will result in a NULL pointer derefence when it calls dev_name() on<br /> that NULL device pointer.<br /> <br /> Add a test for this case and use NULL as the dev_id if the device<br /> pointer is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: qcom_q6v5_mss: Fix some leaks in q6v5_alloc_memory_region<br /> <br /> The device_node pointer is returned by of_parse_phandle() or<br /> of_get_child_by_name() with refcount incremented.<br /> We should use of_node_put() on it when done.<br /> <br /> This function only call of_node_put(node) when of_address_to_resource<br /> succeeds, missing error cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: qcom: clk-rcg2: Update logic to calculate D value for RCG<br /> <br /> The display pixel clock has a requirement on certain newer platforms to<br /> support M/N as (2/3) and the final D value calculated results in<br /> underflow errors.<br /> As the current implementation does not check for D value is within<br /> the accepted range for a given M &amp; N value. Update the logic to<br /> calculate the final D value based on the range.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_ct: fix ref leak when switching zones<br /> <br /> When switching zones or network namespaces without doing a ct clear in<br /> between, it is now leaking a reference to the old ct entry. That&amp;#39;s<br /> because tcf_ct_skb_nfct_cached() returns false and<br /> tcf_ct_flow_table_lookup() may simply overwrite it.<br /> <br /> The fix is to, as the ct entry is not reusable, free it already at<br /> tcf_ct_skb_nfct_cached().