Vulnerabilities

protobufjs-cli is the command line add-on for protobuf.js. Prior to 1.2.1 and 2.0.2, pbjs static code generation could emit unsafe JavaScript identifiers derived from schema-controlled names. When generating static JavaScript from a crafted schema or JSON descriptor, certain namespace, enum, service, or derived full names could be written into the generated output without sufficient sanitization. This vulnerability is fixed in 1.2.1 and 2.0.2.

protobufjs compiles protobuf definitions into JavaScript (JS) functions. Prior to 7.5.6 and 8.0.2, protobufjs could recurse without a depth limit while decoding nested protobuf data. This affected both skipping unknown group fields and generated decoding of nested message fields. A crafted protobuf binary payload could cause the JavaScript call stack to be exhausted during decoding. This vulnerability is fixed in 7.5.6 and 8.0.2.

protobufjs compiles protobuf definitions into JavaScript (JS) functions. Prior to 7.5.6 and 8.0.2, protobufjs used plain objects with inherited prototypes for internal type lookup tables used by generated encode and decode functions. If Object.prototype had already been polluted, those lookup tables could resolve attacker-controlled inherited properties as valid protobuf type information. This could cause attacker-controlled strings to be emitted into generated JavaScript code. This vulnerability is fixed in 7.5.6 and 8.0.2.

protobufjs compiles protobuf definitions into JavaScript (JS) functions. Prior to 7.5.6 and 8.0.2, protobufjs allowed certain schema option paths to traverse through inherited object properties while applying options. A crafted protobuf schema or JSON descriptor could cause option handling to write to properties on global JavaScript constructors, corrupting process-wide built-in functionality. This vulnerability is fixed in 7.5.6 and 8.0.2.

protobufjs compiles protobuf definitions into JavaScript (JS) functions. Prior to 7.5.6 and 8.0.2, protobufjs includes a minimal UTF-8 decoder that accepted overlong UTF-8 byte sequences and decoded them to their canonical characters instead of replacing them. An attacker who can provide protobuf binary data decoded through the affected UTF-8 path may be able to bypass application-level checks that inspect raw bytes before protobuf string decoding. For example, bytes that do not contain certain ASCII characters could decode to strings containing those characters. This vulnerability is fixed in 7.5.6 and 8.0.2.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci: Prevent interrupt storm on host controller error (HCE)<br /> <br /> The xHCI controller reports a Host Controller Error (HCE) in UAS Storage<br /> Device plug/unplug scenarios on Android devices. HCE is checked in<br /> xhci_irq() function and causes an interrupt storm (since the interrupt<br /> isn’t cleared), leading to severe system-level faults.<br /> <br /> When the xHC controller reports HCE in the interrupt handler, the driver<br /> only logs a warning and assumes xHC activity will stop as stated in xHCI<br /> specification. An interrupt storm does however continue on some hosts<br /> even after HCE, and only ceases after manually disabling xHC interrupt<br /> and stopping the controller by calling xhci_halt().<br /> <br /> Add xhci_halt() to xhci_irq() function where STS_HCE status is checked,<br /> mirroring the existing error handling pattern used for STS_FATAL errors.<br /> <br /> This only fixes the interrupt storm. Proper HCE recovery requires resetting<br /> and re-initializing the xHC.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> liveupdate: luo_file: remember retrieve() status<br /> <br /> LUO keeps track of successful retrieve attempts on a LUO file. It does so<br /> to avoid multiple retrievals of the same file. Multiple retrievals cause<br /> problems because once the file is retrieved, the serialized data<br /> structures are likely freed and the file is likely in a very different<br /> state from what the code expects.<br /> <br /> The retrieve boolean in struct luo_file keeps track of this, and is passed<br /> to the finish callback so it knows what work was already done and what it<br /> has left to do.<br /> <br /> All this works well when retrieve succeeds. When it fails,<br /> luo_retrieve_file() returns the error immediately, without ever storing<br /> anywhere that a retrieve was attempted or what its error code was. This<br /> results in an errored LIVEUPDATE_SESSION_RETRIEVE_FD ioctl to userspace,<br /> but nothing prevents it from trying this again.<br /> <br /> The retry is problematic for much of the same reasons listed above. The<br /> file is likely in a very different state than what the retrieve logic<br /> normally expects, and it might even have freed some serialization data<br /> structures. Attempting to access them or free them again is going to<br /> break things.<br /> <br /> For example, if memfd managed to restore 8 of its 10 folios, but fails on<br /> the 9th, a subsequent retrieve attempt will try to call<br /> kho_restore_folio() on the first folio again, and that will fail with a<br /> warning since it is an invalid operation.<br /> <br /> Apart from the retry, finish() also breaks. Since on failure the<br /> retrieved bool in luo_file is never touched, the finish() call on session<br /> close will tell the file handler that retrieve was never attempted, and it<br /> will try to access or free the data structures that might not exist, much<br /> in the same way as the retry attempt.<br /> <br /> There is no sane way of attempting the retrieve again. Remember the error<br /> retrieve returned and directly return it on a retry. Also pass this<br /> status code to finish() so it can make the right decision on the work it<br /> needs to do.<br /> <br /> This is done by changing the bool to an integer. A value of 0 means<br /> retrieve was never attempted, a positive value means it succeeded, and a<br /> negative value means it failed and the error code is the value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect<br /> <br /> Remove redundant netif_napi_del() call from disconnect path.<br /> <br /> A WARN may be triggered in __netif_napi_del_locked() during USB device<br /> disconnect:<br /> <br /> WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350<br /> <br /> This happens because netif_napi_del() is called in the disconnect path while<br /> NAPI is still enabled. However, it is not necessary to call netif_napi_del()<br /> explicitly, since unregister_netdev() will handle NAPI teardown automatically<br /> and safely. Removing the redundant call avoids triggering the warning.<br /> <br /> Full trace:<br /> lan78xx 1-1:1.0 enu1: Failed to read register index 0x000000c4. ret = -ENODEV<br /> lan78xx 1-1:1.0 enu1: Failed to set MAC down with error -ENODEV<br /> lan78xx 1-1:1.0 enu1: Link is Down<br /> lan78xx 1-1:1.0 enu1: Failed to read register index 0x00000120. ret = -ENODEV<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350<br /> Modules linked in: flexcan can_dev fuse<br /> CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.0-rc2-00624-ge926949dab03 #9 PREEMPT<br /> Hardware name: SKOV IMX8MP CPU revC - bd500 (DT)<br /> Workqueue: usb_hub_wq hub_event<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __netif_napi_del_locked+0x2b4/0x350<br /> lr : __netif_napi_del_locked+0x7c/0x350<br /> sp : ffffffc085b673c0<br /> x29: ffffffc085b673c0 x28: ffffff800b7f2000 x27: ffffff800b7f20d8<br /> x26: ffffff80110bcf58 x25: ffffff80110bd978 x24: 1ffffff0022179eb<br /> x23: ffffff80110bc000 x22: ffffff800b7f5000 x21: ffffff80110bc000<br /> x20: ffffff80110bcf38 x19: ffffff80110bcf28 x18: dfffffc000000000<br /> x17: ffffffc081578940 x16: ffffffc08284cee0 x15: 0000000000000028<br /> x14: 0000000000000006 x13: 0000000000040000 x12: ffffffb0022179e8<br /> x11: 1ffffff0022179e7 x10: ffffffb0022179e7 x9 : dfffffc000000000<br /> x8 : 0000004ffdde8619 x7 : ffffff80110bcf3f x6 : 0000000000000001<br /> x5 : ffffff80110bcf38 x4 : ffffff80110bcf38 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : 1ffffff0022179e7 x0 : 0000000000000000<br /> Call trace:<br /> __netif_napi_del_locked+0x2b4/0x350 (P)<br /> lan78xx_disconnect+0xf4/0x360<br /> usb_unbind_interface+0x158/0x718<br /> device_remove+0x100/0x150<br /> device_release_driver_internal+0x308/0x478<br /> device_release_driver+0x1c/0x30<br /> bus_remove_device+0x1a8/0x368<br /> device_del+0x2e0/0x7b0<br /> usb_disable_device+0x244/0x540<br /> usb_disconnect+0x220/0x758<br /> hub_event+0x105c/0x35e0<br /> process_one_work+0x760/0x17b0<br /> worker_thread+0x768/0xce8<br /> kthread+0x3bc/0x690<br /> ret_from_fork+0x10/0x20<br /> irq event stamp: 211604<br /> hardirqs last enabled at (211603): [] _raw_spin_unlock_irqrestore+0x84/0x98<br /> hardirqs last disabled at (211604): [] el1_dbg+0x24/0x80<br /> softirqs last enabled at (211296): [] handle_softirqs+0x820/0xbc8<br /> softirqs last disabled at (210993): [] __do_softirq+0x18/0x20<br /> ---[ end trace 0000000000000000 ]---<br /> lan78xx 1-1:1.0 enu1: failed to kill vid 0081/0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock acquisition<br /> <br /> The acp3x_5682_init() function did not check the return value of<br /> clk_get(), which could lead to dereferencing error pointers in<br /> rt5682_clk_enable().<br /> <br /> Fix this by:<br /> 1. Changing clk_get() to the device-managed devm_clk_get().<br /> 2. Adding proper IS_ERR() checks for both clock acquisitions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net-shapers: don&amp;#39;t free reply skb after genlmsg_reply()<br /> <br /> genlmsg_reply() hands the reply skb to netlink, and<br /> netlink_unicast() consumes it on all return paths, whether the<br /> skb is queued successfully or freed on an error path.<br /> <br /> net_shaper_nl_get_doit() and net_shaper_nl_cap_get_doit()<br /> currently jump to free_msg after genlmsg_reply() fails and call<br /> nlmsg_free(msg), which can hit the same skb twice.<br /> <br /> Return the genlmsg_reply() error directly and keep free_msg<br /> only for pre-reply failures.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Disable preemption between scx_claim_exit() and kicking helper work<br /> <br /> scx_claim_exit() atomically sets exit_kind, which prevents scx_error() from<br /> triggering further error handling. After claiming exit, the caller must kick<br /> the helper kthread work which initiates bypass mode and teardown.<br /> <br /> If the calling task gets preempted between claiming exit and kicking the<br /> helper work, and the BPF scheduler fails to schedule it back (since error<br /> handling is now disabled), the helper work is never queued, bypass mode<br /> never activates, tasks stop being dispatched, and the system wedges.<br /> <br /> Disable preemption across scx_claim_exit() and the subsequent work kicking<br /> in all callers - scx_disable() and scx_vexit(). Add<br /> lockdep_assert_preemption_disabled() to scx_claim_exit() to enforce the<br /> requirement.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated<br /> <br /> Explicitly set/clear CR8 write interception when AVIC is (de)activated to<br /> fix a bug where KVM leaves the interception enabled after AVIC is<br /> activated. E.g. if KVM emulates INIT=&gt;WFS while AVIC is deactivated, CR8<br /> will remain intercepted in perpetuity.<br /> <br /> On its own, the dangling CR8 intercept is "just" a performance issue, but<br /> combined with the TPR sync bug fixed by commit d02e48830e3f ("KVM: SVM:<br /> Sync TPR from LAPIC into VMCB::V_TPR even if AVIC is active"), the danging<br /> intercept is fatal to Windows guests as the TPR seen by hardware gets<br /> wildly out of sync with reality.<br /> <br /> Note, VMX isn&amp;#39;t affected by the bug as TPR_THRESHOLD is explicitly ignored<br /> when Virtual Interrupt Delivery is enabled, i.e. when APICv is active in<br /> KVM&amp;#39;s world. I.e. there&amp;#39;s no need to trigger update_cr8_intercept(), this<br /> is firmly an SVM implementation flaw/detail.<br /> <br /> WARN if KVM gets a CR8 write #VMEXIT while AVIC is active, as KVM should<br /> never enter the guest with AVIC enabled and CR8 writes intercepted.<br /> <br /> [Squash fix to avic_deactivate_vmcb. - Paolo]