Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: prevent potential spectre v1 gadget in fib_metrics_match()<br /> <br /> if (!type)<br /> continue;<br /> if (type &gt; RTAX_MAX)<br /> return false;<br /> ...<br /> fi_val = fi-&gt;fib_metrics-&gt;metrics[type - 1];<br /> <br /> @type being used as an array index, we need to prevent<br /> cpu speculation or risk leaking kernel memory content.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: prevent potential spectre v1 gadget in ip_metrics_convert()<br /> <br /> if (!type)<br /> continue;<br /> if (type &gt; RTAX_MAX)<br /> return -EINVAL;<br /> ...<br /> metrics[type - 1] = val;<br /> <br /> @type being used as an array index, we need to prevent<br /> cpu speculation or risk leaking kernel memory content.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fec: Use page_pool_put_full_page when freeing rx buffers<br /> <br /> The page_pool_release_page was used when freeing rx buffers, and this<br /> function just unmaps the page (if mapped) and does not recycle the page.<br /> So after hundreds of down/up the eth0, the system will out of memory.<br /> For more details, please refer to the following reproduce steps and<br /> bug logs. To solve this issue and refer to the doc of page pool, the<br /> page_pool_put_full_page should be used to replace page_pool_release_page.<br /> Because this API will try to recycle the page if the page refcnt equal to<br /> 1. After testing 20000 times, the issue can not be reproduced anymore<br /> (about testing 391 times the issue will occur on i.MX8MN-EVK before).<br /> <br /> Reproduce steps:<br /> Create the test script and run the script. The script content is as<br /> follows:<br /> LOOPS=20000<br /> i=1<br /> while [ $i -le $LOOPS ]<br /> do<br /> echo "TINFO:ENET $curface up and down test $i times"<br /> org_macaddr=$(cat /sys/class/net/eth0/address)<br /> ifconfig eth0 down<br /> ifconfig eth0 hw ether $org_macaddr up<br /> i=$(expr $i + 1)<br /> done<br /> sleep 5<br /> if cat /sys/class/net/eth0/operstate | grep &amp;#39;up&amp;#39;;then<br /> echo "TEST PASS"<br /> else<br /> echo "TEST FAIL"<br /> fi<br /> <br /> Bug detail logs:<br /> TINFO:ENET up and down test 391 times<br /> [ 850.471205] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL)<br /> [ 853.535318] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready<br /> [ 853.541694] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx<br /> [ 870.590531] page_pool_release_retry() stalled pool shutdown 199 inflight 60 sec<br /> [ 931.006557] page_pool_release_retry() stalled pool shutdown 199 inflight 120 sec<br /> TINFO:ENET up and down test 392 times<br /> [ 991.426544] page_pool_release_retry() stalled pool shutdown 192 inflight 181 sec<br /> [ 1051.838531] page_pool_release_retry() stalled pool shutdown 170 inflight 241 sec<br /> [ 1093.751217] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL)<br /> [ 1096.446520] page_pool_release_retry() stalled pool shutdown 308 inflight 60 sec<br /> [ 1096.831245] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx<br /> [ 1096.839092] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready<br /> [ 1112.254526] page_pool_release_retry() stalled pool shutdown 103 inflight 302 sec<br /> [ 1156.862533] page_pool_release_retry() stalled pool shutdown 308 inflight 120 sec<br /> [ 1172.674516] page_pool_release_retry() stalled pool shutdown 103 inflight 362 sec<br /> [ 1217.278532] page_pool_release_retry() stalled pool shutdown 308 inflight 181 sec<br /> TINFO:ENET up and down test 393 times<br /> [ 1233.086535] page_pool_release_retry() stalled pool shutdown 103 inflight 422 sec<br /> [ 1277.698513] page_pool_release_retry() stalled pool shutdown 308 inflight 241 sec<br /> [ 1293.502525] page_pool_release_retry() stalled pool shutdown 86 inflight 483 sec<br /> [ 1338.110518] page_pool_release_retry() stalled pool shutdown 308 inflight 302 sec<br /> [ 1353.918540] page_pool_release_retry() stalled pool shutdown 32 inflight 543 sec<br /> [ 1361.179205] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL)<br /> [ 1364.255298] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx<br /> [ 1364.263189] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready<br /> [ 1371.998532] page_pool_release_retry() stalled pool shutdown 310 inflight 60 sec<br /> [ 1398.530542] page_pool_release_retry() stalled pool shutdown 308 inflight 362 sec<br /> [ 1414.334539] page_pool_release_retry() stalled pool shutdown 16 inflight 604 sec<br /> [ 1432.414520] page_pool_release_retry() stalled pool shutdown 310 inflight 120 sec<br /> [ 1458.942523] page_pool_release_retry() stalled pool shutdown 308 inflight 422 sec<br /> [ 1474.750521] page_pool_release_retry() stalled pool shutdown 16 inflight 664 sec<br /> TINFO:ENET up and down test 394 times<br /> [ 1492.8305<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netlink: prevent potential spectre v1 gadgets<br /> <br /> Most netlink attributes are parsed and validated from<br /> __nla_validate_parse() or validate_nla()<br /> <br /> u16 type = nla_type(nla);<br /> <br /> if (type == 0 || type &gt; maxtype) {<br /> /* error or continue */<br /> }<br /> <br /> @type is then used as an array index and can be used<br /> as a Spectre v1 gadget.<br /> <br /> array_index_nospec() can be used to prevent leaking<br /> content of kernel memory to malicious users.<br /> <br /> This should take care of vast majority of netlink uses,<br /> but an audit is needed to take care of others where<br /> validation is not yet centralized in core netlink functions.

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: fix UaF in netns ops registration error path<br /> <br /> If net_assign_generic() fails, the current error path in ops_init() tries<br /> to clear the gen pointer slot. Anyway, in such error path, the gen pointer<br /> itself has not been modified yet, and the existing and accessed one is<br /> smaller than the accessed index, causing an out-of-bounds error:<br /> <br /> BUG: KASAN: slab-out-of-bounds in ops_init+0x2de/0x320<br /> Write of size 8 at addr ffff888109124978 by task modprobe/1018<br /> <br /> CPU: 2 PID: 1018 Comm: modprobe Not tainted 6.2.0-rc2.mptcp_ae5ac65fbed5+ #1641<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6a/0x9f<br /> print_address_description.constprop.0+0x86/0x2b5<br /> print_report+0x11b/0x1fb<br /> kasan_report+0x87/0xc0<br /> ops_init+0x2de/0x320<br /> register_pernet_operations+0x2e4/0x750<br /> register_pernet_subsys+0x24/0x40<br /> tcf_register_action+0x9f/0x560<br /> do_one_initcall+0xf9/0x570<br /> do_init_module+0x190/0x650<br /> load_module+0x1fa5/0x23c0<br /> __do_sys_finit_module+0x10d/0x1b0<br /> do_syscall_64+0x58/0x80<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> RIP: 0033:0x7f42518f778d<br /> Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48<br /> 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff<br /> ff 73 01 c3 48 8b 0d cb 56 2c 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007fff96869688 EFLAGS: 00000246 ORIG_RAX: 0000000000000139<br /> RAX: ffffffffffffffda RBX: 00005568ef7f7c90 RCX: 00007f42518f778d<br /> RDX: 0000000000000000 RSI: 00005568ef41d796 RDI: 0000000000000003<br /> RBP: 00005568ef41d796 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00005568ef7f7d30 R14: 0000000000040000 R15: 0000000000000000<br /> <br /> <br /> This change addresses the issue by skipping the gen pointer<br /> de-reference in the mentioned error-path.<br /> <br /> Found by code inspection and verified with explicit error injection<br /> on a kasan-enabled kernel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> acpi: Fix suspend with Xen PV<br /> <br /> Commit f1e525009493 ("x86/boot: Skip realmode init code when running as<br /> Xen PV guest") missed one code path accessing real_mode_header, leading<br /> to dereferencing NULL when suspending the system under Xen:<br /> <br /> [ 348.284004] PM: suspend entry (deep)<br /> [ 348.289532] Filesystems sync: 0.005 seconds<br /> [ 348.291545] Freezing user space processes ... (elapsed 0.000 seconds) done.<br /> [ 348.292457] OOM killer disabled.<br /> [ 348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 seconds) done.<br /> [ 348.396612] printk: Suspending console(s) (use no_console_suspend to debug)<br /> [ 348.749228] PM: suspend devices took 0.352 seconds<br /> [ 348.769713] ACPI: EC: interrupt blocked<br /> [ 348.816077] BUG: kernel NULL pointer dereference, address: 000000000000001c<br /> [ 348.816080] #PF: supervisor read access in kernel mode<br /> [ 348.816081] #PF: error_code(0x0000) - not-present page<br /> [ 348.816083] PGD 0 P4D 0<br /> [ 348.816086] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 6.1.3-1.fc32.qubes.x86_64 #1<br /> [ 348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 07/03/2022<br /> [ 348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20<br /> <br /> Fix that by adding an optional acpi callback allowing to skip setting<br /> the wakeup address, as in the Xen PV case this will be handled by the<br /> hypervisor anyway.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda/via: Avoid potential array out-of-bound in add_secret_dac_path()<br /> <br /> snd_hda_get_connections() can return a negative error code.<br /> It may lead to accessing &amp;#39;conn&amp;#39; array at a negative index.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firewire: fix memory leak for payload of request subaction to IEC 61883-1 FCP region<br /> <br /> This patch is fix for Linux kernel v2.6.33 or later.<br /> <br /> For request subaction to IEC 61883-1 FCP region, Linux FireWire subsystem<br /> have had an issue of use-after-free. The subsystem allows multiple<br /> user space listeners to the region, while data of the payload was likely<br /> released before the listeners execute read(2) to access to it for copying<br /> to user space.<br /> <br /> The issue was fixed by a commit 281e20323ab7 ("firewire: core: fix<br /> use-after-free regression in FCP handler"). The object of payload is<br /> duplicated in kernel space for each listener. When the listener executes<br /> ioctl(2) with FW_CDEV_IOC_SEND_RESPONSE request, the object is going to<br /> be released.<br /> <br /> However, it causes memory leak since the commit relies on call of<br /> release_request() in drivers/firewire/core-cdev.c. Against the<br /> expectation, the function is never called due to the design of<br /> release_client_resource(). The function delegates release task<br /> to caller when called with non-NULL fourth argument. The implementation<br /> of ioctl_send_response() is the case. It should release the object<br /> explicitly.<br /> <br /> This commit fixes the bug.

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 /> bpf: Skip task with pid=1 in send_signal_common()<br /> <br /> The following kernel panic can be triggered when a task with pid=1 attaches<br /> a prog that attempts to send killing signal to itself, also see [1] for more<br /> details:<br /> <br /> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b<br /> CPU: 3 PID: 1 Comm: systemd Not tainted 6.1.0-09652-g59fe41b5255f #148<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x100/0x178 lib/dump_stack.c:106<br /> panic+0x2c4/0x60f kernel/panic.c:275<br /> do_exit.cold+0x63/0xe4 kernel/exit.c:789<br /> do_group_exit+0xd4/0x2a0 kernel/exit.c:950<br /> get_signal+0x2460/0x2600 kernel/signal.c:2858<br /> arch_do_signal_or_restart+0x78/0x5d0 arch/x86/kernel/signal.c:306<br /> exit_to_user_mode_loop kernel/entry/common.c:168 [inline]<br /> exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]<br /> syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296<br /> do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> So skip task with pid=1 in bpf_send_signal_common() to avoid the panic.<br /> <br /> [1] https://lore.kernel.org/bpf/20221222043507.33037-1-sunhao.th@gmail.com

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL<br /> <br /> Baoquan reported that after triggering a crash the subsequent crash-kernel<br /> fails to boot about half of the time. It triggers a NULL pointer<br /> dereference in the periodic tick code.<br /> <br /> This happens because the legacy timer interrupt (IRQ0) is resent in<br /> software which happens in soft interrupt (tasklet) context. In this context<br /> get_irq_regs() returns NULL which leads to the NULL pointer dereference.<br /> <br /> The reason for the resend is a spurious APIC interrupt on the IRQ0 vector<br /> which is captured and leads to a resend when the legacy timer interrupt is<br /> enabled. This is wrong because the legacy PIC interrupts are level<br /> triggered and therefore should never be resent in software, but nothing<br /> ever sets the IRQ_LEVEL flag on those interrupts, so the core code does not<br /> know about their trigger type.<br /> <br /> Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up.