Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu/nocb: Fix WARN_ON_ONCE() in the rcu_nocb_bypass_lock()<br /> <br /> For the kernels built with CONFIG_RCU_NOCB_CPU_DEFAULT_ALL=y and<br /> CONFIG_RCU_LAZY=y, the following scenarios will trigger WARN_ON_ONCE()<br /> in the rcu_nocb_bypass_lock() and rcu_nocb_wait_contended() functions:<br /> <br /> CPU2 CPU11<br /> kthread<br /> rcu_nocb_cb_kthread ksys_write<br /> rcu_do_batch vfs_write<br /> rcu_torture_timer_cb proc_sys_write<br /> __kmem_cache_free proc_sys_call_handler<br /> kmemleak_free drop_caches_sysctl_handler<br /> delete_object_full drop_slab<br /> __delete_object shrink_slab<br /> put_object lazy_rcu_shrink_scan<br /> call_rcu rcu_nocb_flush_bypass<br /> __call_rcu_commn rcu_nocb_bypass_lock<br /> raw_spin_trylock(&amp;rdp-&gt;nocb_bypass_lock) fail<br /> atomic_inc(&amp;rdp-&gt;nocb_lock_contended);<br /> rcu_nocb_wait_contended WARN_ON_ONCE(smp_processor_id() != rdp-&gt;cpu);<br /> WARN_ON_ONCE(atomic_read(&amp;rdp-&gt;nocb_lock_contended)) |<br /> |_ _ _ _ _ _ _ _ _ _same rdp and rdp-&gt;cpu != 11_ _ _ _ _ _ _ _ _ __|<br /> <br /> Reproduce this bug with "echo 3 &gt; /proc/sys/vm/drop_caches".<br /> <br /> This commit therefore uses rcu_nocb_try_flush_bypass() instead of<br /> rcu_nocb_flush_bypass() in lazy_rcu_shrink_scan(). If the nocb_bypass<br /> queue is being flushed, then rcu_nocb_try_flush_bypass will return<br /> directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sysv: don&amp;#39;t call sb_bread() with pointers_lock held<br /> <br /> syzbot is reporting sleep in atomic context in SysV filesystem [1], for<br /> sb_bread() is called with rw_spinlock held.<br /> <br /> A "write_lock(&amp;pointers_lock) =&gt; read_lock(&amp;pointers_lock) deadlock" bug<br /> and a "sb_bread() with write_lock(&amp;pointers_lock)" bug were introduced by<br /> "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.<br /> <br /> Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the<br /> former bug by moving pointers_lock lock to the callers, but instead<br /> introduced a "sb_bread() with read_lock(&amp;pointers_lock)" bug (which made<br /> this problem easier to hit).<br /> <br /> Al Viro suggested that why not to do like get_branch()/get_block()/<br /> find_shared() in Minix filesystem does. And doing like that is almost a<br /> revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch()<br /> from with find_shared() is called without write_lock(&amp;pointers_lock).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-buf: Fix NULL pointer dereference in sanitycheck()<br /> <br /> If due to a memory allocation failure mock_chain() returns NULL, it is<br /> passed to dma_fence_enable_sw_signaling() resulting in NULL pointer<br /> dereference there.<br /> <br /> Call dma_fence_enable_sw_signaling() only if mock_chain() succeeds.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/bpf: Fix bpf_plt pointer arithmetic<br /> <br /> Kui-Feng Lee reported a crash on s390x triggered by the<br /> dummy_st_ops/dummy_init_ptr_arg test [1]:<br /> <br /> [] 0x2<br /> [] bpf_struct_ops_test_run+0x156/0x250<br /> [] __sys_bpf+0xa1a/0xd00<br /> [] __s390x_sys_bpf+0x44/0x50<br /> [] __do_syscall+0x244/0x300<br /> [] system_call+0x70/0x98<br /> <br /> This is caused by GCC moving memcpy() after assignments in<br /> bpf_jit_plt(), resulting in NULL pointers being written instead of<br /> the return and the target addresses.<br /> <br /> Looking at the GCC internals, the reordering is allowed because the<br /> alias analysis thinks that the memcpy() destination and the assignments&amp;#39;<br /> left-hand-sides are based on different objects: new_plt and<br /> bpf_plt_ret/bpf_plt_target respectively, and therefore they cannot<br /> alias.<br /> <br /> This is in turn due to a violation of the C standard:<br /> <br /> When two pointers are subtracted, both shall point to elements of the<br /> same array object, or one past the last element of the array object<br /> ...<br /> <br /> From the C&amp;#39;s perspective, bpf_plt_ret and bpf_plt are distinct objects<br /> and cannot be subtracted. In the practical terms, doing so confuses the<br /> GCC&amp;#39;s alias analysis.<br /> <br /> The code was written this way in order to let the C side know a few<br /> offsets defined in the assembly. While nice, this is by no means<br /> necessary. Fix the noncompliance by hardcoding these offsets.<br /> <br /> [1] https://lore.kernel.org/bpf/c9923c1d-971d-4022-8dc8-1364e929d34c@gmail.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rds: fix possible cp null dereference<br /> <br /> cp might be null, calling cp-&gt;cp_conn would produce null dereference<br /> <br /> [Simon Horman adds:]<br /> <br /> Analysis:<br /> <br /> * cp is a parameter of __rds_rdma_map and is not reassigned.<br /> <br /> * The following call-sites pass a NULL cp argument to __rds_rdma_map()<br /> <br /> - rds_get_mr()<br /> - rds_get_mr_for_dest<br /> <br /> * Prior to the code above, the following assumes that cp may be NULL<br /> (which is indicative, but could itself be unnecessary)<br /> <br /> trans_private = rs-&gt;rs_transport-&gt;get_mr(<br /> sg, nents, rs, &amp;mr-&gt;r_key, cp ? cp-&gt;cp_conn : NULL,<br /> args-&gt;vec.addr, args-&gt;vec.bytes,<br /> need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED);<br /> <br /> * The code modified by this patch is guarded by IS_ERR(trans_private),<br /> where trans_private is assigned as per the previous point in this analysis.<br /> <br /> The only implementation of get_mr that I could locate is rds_ib_get_mr()<br /> which can return an ERR_PTR if the conn (4th) argument is NULL.<br /> <br /> * ret is set to PTR_ERR(trans_private).<br /> rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL.<br /> Thus ret may be -ENODEV in which case the code in question will execute.<br /> <br /> Conclusion:<br /> * cp may be NULL at the point where this patch adds a check;<br /> this patch does seem to address a possible bug

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/bpf: Fix IP after emitting call depth accounting<br /> <br /> Adjust the IP passed to `emit_patch` so it calculates the correct offset<br /> for the CALL instruction if `x86_call_depth_emit_accounting` emits code.<br /> Otherwise we will skip some instructions and most likely crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> selinux: avoid dereference of garbage after mount failure<br /> <br /> In case kern_mount() fails and returns an error pointer return in the<br /> error branch instead of continuing and dereferencing the error pointer.<br /> <br /> While on it drop the never read static variable selinuxfs_mount.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Protect against int overflow for stack access size<br /> <br /> This patch re-introduces protection against the size of access to stack<br /> memory being negative; the access size can appear negative as a result<br /> of overflowing its signed int representation. This should not actually<br /> happen, as there are other protections along the way, but we should<br /> protect against it anyway. One code path was missing such protections<br /> (fixed in the previous patch in the series), causing out-of-bounds array<br /> accesses in check_stack_range_initialized(). This patch causes the<br /> verification of a program with such a non-sensical access size to fail.<br /> <br /> This check used to exist in a more indirect way, but was inadvertendly<br /> removed in a833a17aeac7.

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 /> mlxbf_gige: call request_irq() after NAPI initialized<br /> <br /> The mlxbf_gige driver encounters a NULL pointer exception in<br /> mlxbf_gige_open() when kdump is enabled. The sequence to reproduce<br /> the exception is as follows:<br /> a) enable kdump<br /> b) trigger kdump via "echo c &gt; /proc/sysrq-trigger"<br /> c) kdump kernel executes<br /> d) kdump kernel loads mlxbf_gige module<br /> e) the mlxbf_gige module runs its open() as the<br /> the "oob_net0" interface is brought up<br /> f) mlxbf_gige module will experience an exception<br /> during its open(), something like:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> Mem abort info:<br /> ESR = 0x0000000086000004<br /> EC = 0x21: IABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e29a4000<br /> [0000000000000000] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 0000000086000004 [#1] SMP<br /> CPU: 0 PID: 812 Comm: NetworkManager Tainted: G OE 5.15.0-1035-bluefield #37-Ubuntu<br /> Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.6.0.13024 Jan 19 2024<br /> pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : 0x0<br /> lr : __napi_poll+0x40/0x230<br /> sp : ffff800008003e00<br /> x29: ffff800008003e00 x28: 0000000000000000 x27: 00000000ffffffff<br /> x26: ffff000066027238 x25: ffff00007cedec00 x24: ffff800008003ec8<br /> x23: 000000000000012c x22: ffff800008003eb7 x21: 0000000000000000<br /> x20: 0000000000000001 x19: ffff000066027238 x18: 0000000000000000<br /> x17: ffff578fcb450000 x16: ffffa870b083c7c0 x15: 0000aaab010441d0<br /> x14: 0000000000000001 x13: 00726f7272655f65 x12: 6769675f6662786c<br /> x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa870b0842398<br /> x8 : 0000000000000004 x7 : fe5a48b9069706ea x6 : 17fdb11fc84ae0d2<br /> x5 : d94a82549d594f35 x4 : 0000000000000000 x3 : 0000000000400100<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000066027238<br /> Call trace:<br /> 0x0<br /> net_rx_action+0x178/0x360<br /> __do_softirq+0x15c/0x428<br /> __irq_exit_rcu+0xac/0xec<br /> irq_exit+0x18/0x2c<br /> handle_domain_irq+0x6c/0xa0<br /> gic_handle_irq+0xec/0x1b0<br /> call_on_irq_stack+0x20/0x2c<br /> do_interrupt_handler+0x5c/0x70<br /> el1_interrupt+0x30/0x50<br /> el1h_64_irq_handler+0x18/0x2c<br /> el1h_64_irq+0x7c/0x80<br /> __setup_irq+0x4c0/0x950<br /> request_threaded_irq+0xf4/0x1bc<br /> mlxbf_gige_request_irqs+0x68/0x110 [mlxbf_gige]<br /> mlxbf_gige_open+0x5c/0x170 [mlxbf_gige]<br /> __dev_open+0x100/0x220<br /> __dev_change_flags+0x16c/0x1f0<br /> dev_change_flags+0x2c/0x70<br /> do_setlink+0x220/0xa40<br /> __rtnl_newlink+0x56c/0x8a0<br /> rtnl_newlink+0x58/0x84<br /> rtnetlink_rcv_msg+0x138/0x3c4<br /> netlink_rcv_skb+0x64/0x130<br /> rtnetlink_rcv+0x20/0x30<br /> netlink_unicast+0x2ec/0x360<br /> netlink_sendmsg+0x278/0x490<br /> __sock_sendmsg+0x5c/0x6c<br /> ____sys_sendmsg+0x290/0x2d4<br /> ___sys_sendmsg+0x84/0xd0<br /> __sys_sendmsg+0x70/0xd0<br /> __arm64_sys_sendmsg+0x2c/0x40<br /> invoke_syscall+0x78/0x100<br /> el0_svc_common.constprop.0+0x54/0x184<br /> do_el0_svc+0x30/0xac<br /> el0_svc+0x48/0x160<br /> el0t_64_sync_handler+0xa4/0x12c<br /> el0t_64_sync+0x1a4/0x1a8<br /> Code: bad PC value<br /> ---[ end trace 7d1c3f3bf9d81885 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception in interrupt<br /> Kernel Offset: 0x2870a7a00000 from 0xffff800008000000<br /> PHYS_OFFSET: 0x80000000<br /> CPU features: 0x0,000005c1,a3332a5a<br /> Memory Limit: none<br /> ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---<br /> <br /> The exception happens because there is a pending RX interrupt before the<br /> call to request_irq(RX IRQ) executes. Then, the RX IRQ handler fires<br /> immediately after this request_irq() completes. The<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tls: get psock ref after taking rxlock to avoid leak<br /> <br /> At the start of tls_sw_recvmsg, we take a reference on the psock, and<br /> then call tls_rx_reader_lock. If that fails, we return directly<br /> without releasing the reference.<br /> <br /> Instead of adding a new label, just take the reference after locking<br /> has succeeded, since we don&amp;#39;t need it before.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wwan: t7xx: Split 64bit accesses to fix alignment issues<br /> <br /> Some of the registers are aligned on a 32bit boundary, causing<br /> alignment faults on 64bit platforms.<br /> <br /> Unable to handle kernel paging request at virtual address ffffffc084a1d004<br /> Mem abort info:<br /> ESR = 0x0000000096000061<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x21: alignment fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000061, ISS2 = 0x00000000<br /> CM = 0, WnR = 1, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000046ad6000<br /> [ffffffc084a1d004] pgd=100000013ffff003, p4d=100000013ffff003, pud=100000013ffff003, pmd=0068000020a00711<br /> Internal error: Oops: 0000000096000061 [#1] SMP<br /> Modules linked in: mtk_t7xx(+) qcserial pppoe ppp_async option nft_fib_inet nf_flow_table_inet mt7921u(O) mt7921s(O) mt7921e(O) mt7921_common(O) iwlmvm(O) iwldvm(O) usb_wwan rndis_host qmi_wwan pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7996e(O) mt792x_usb(O) mt792x_lib(O) mt7915e(O) mt76_usb(O) mt76_sdio(O) mt76_connac_lib(O) mt76(O) mac80211(O) iwlwifi(O) huawei_cdc_ncm cfg80211(O) cdc_ncm cdc_ether wwan usbserial usbnet slhc sfp rtc_pcf8563 nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 mt6577_auxadc mdio_i2c libcrc32c compat(O) cdc_wdm cdc_acm at24 crypto_safexcel pwm_fan i2c_gpio i2c_smbus industrialio i2c_algo_bit i2c_mux_reg i2c_mux_pca954x i2c_mux_pca9541 i2c_mux_gpio i2c_mux dummy oid_registry tun sha512_arm64 sha1_ce sha1_generic seqiv<br /> md5 geniv des_generic libdes cbc authencesn authenc leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd nvme nvme_core gpio_button_hotplug(O) dm_mirror dm_region_hash dm_log dm_crypt dm_mod dax usbcore usb_common ptp aquantia pps_core mii tpm encrypted_keys trusted<br /> CPU: 3 PID: 5266 Comm: kworker/u9:1 Tainted: G O 6.6.22 #0<br /> Hardware name: Bananapi BPI-R4 (DT)<br /> Workqueue: md_hk_wq t7xx_fsm_uninit [mtk_t7xx]<br /> pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx]<br /> lr : t7xx_cldma_start+0xac/0x13c [mtk_t7xx]<br /> sp : ffffffc085d63d30<br /> x29: ffffffc085d63d30 x28: 0000000000000000 x27: 0000000000000000<br /> x26: 0000000000000000 x25: ffffff80c804f2c0 x24: ffffff80ca196c05<br /> x23: 0000000000000000 x22: ffffff80c814b9b8 x21: ffffff80c814b128<br /> x20: 0000000000000001 x19: ffffff80c814b080 x18: 0000000000000014<br /> x17: 0000000055c9806b x16: 000000007c5296d0 x15: 000000000f6bca68<br /> x14: 00000000dbdbdce4 x13: 000000001aeaf72a x12: 0000000000000001<br /> x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000<br /> x8 : ffffff80ca1ef6b4 x7 : ffffff80c814b818 x6 : 0000000000000018<br /> x5 : 0000000000000870 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 000000010a947000 x1 : ffffffc084a1d004 x0 : ffffffc084a1d004<br /> Call trace:<br /> t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx]<br /> t7xx_fsm_uninit+0x578/0x5ec [mtk_t7xx]<br /> process_one_work+0x154/0x2a0<br /> worker_thread+0x2ac/0x488<br /> kthread+0xe0/0xec<br /> ret_from_fork+0x10/0x20<br /> Code: f9400800 91001000 8b214001 d50332bf (f9000022)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The inclusion of io-64-nonatomic-lo-hi.h indicates that all 64bit<br /> accesses can be replaced by pairs of nonatomic 32bit access. Fix<br /> alignment by forcing all accesses to be 32bit on 64bit platforms.