Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btbcm: Fix NULL deref in btbcm_get_board_name()<br /> <br /> devm_kstrdup() can return a NULL pointer on failure,but this<br /> returned value in btbcm_get_board_name() is not checked.<br /> Add NULL check in btbcm_get_board_name(), to handle kernel NULL<br /> pointer dereference error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7925: fix NULL deref check in mt7925_change_vif_links<br /> <br /> In mt7925_change_vif_links() devm_kzalloc() may return NULL but this<br /> returned value is not checked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections<br /> <br /> A report in 2019 by the syzbot fuzzer was found to be connected to two<br /> errors in the HID core associated with Resolution Multipliers. One of<br /> the errors was fixed by commit ea427a222d8b ("HID: core: Fix deadloop<br /> in hid_apply_multiplier."), but the other has not been fixed.<br /> <br /> This error arises because hid_apply_multipler() assumes that every<br /> Resolution Multiplier control is contained in a Logical Collection,<br /> i.e., there&amp;#39;s no way the routine can ever set multiplier_collection to<br /> NULL. This is in spite of the fact that the function starts with a<br /> big comment saying:<br /> <br /> * "The Resolution Multiplier control must be contained in the same<br /> * Logical Collection as the control(s) to which it is to be applied.<br /> ...<br /> * If no Logical Collection is<br /> * defined, the Resolution Multiplier is associated with all<br /> * controls in the report."<br /> * HID Usage Table, v1.12, Section 4.3.1, p30<br /> *<br /> * Thus, search from the current collection upwards until we find a<br /> * logical collection...<br /> <br /> The comment and the code overlook the possibility that none of the<br /> collections found may be a Logical Collection.<br /> <br /> The fix is to set the multiplier_collection pointer to NULL if the<br /> collection found isn&amp;#39;t a Logical Collection.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: th1520: Fix memory corruption due to incorrect array size<br /> <br /> The functions th1520_mbox_suspend_noirq and th1520_mbox_resume_noirq are<br /> intended to save and restore the interrupt mask registers in the MBOX<br /> ICU0. However, the array used to store these registers was incorrectly<br /> sized, leading to memory corruption when accessing all four registers.<br /> <br /> This commit corrects the array size to accommodate all four interrupt<br /> mask registers, preventing memory corruption during suspend and resume<br /> operations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: dw: Fix use-after-free in dw_i3c_master driver due to race condition<br /> <br /> In dw_i3c_common_probe, &amp;master-&gt;hj_work is bound with<br /> dw_i3c_hj_work. And dw_i3c_master_irq_handler can call<br /> dw_i3c_master_irq_handle_ibis function to start the work.<br /> <br /> If we remove the module which will call dw_i3c_common_remove to<br /> make cleanup, it will free master-&gt;base through i3c_master_unregister<br /> while the work mentioned above will be used. The sequence of operations<br /> that may lead to a UAF bug is as follows:<br /> <br /> CPU0 CPU1<br /> <br /> | dw_i3c_hj_work<br /> dw_i3c_common_remove |<br /> i3c_master_unregister(&amp;master-&gt;base) |<br /> device_unregister(&amp;master-&gt;dev) |<br /> device_release |<br /> //free master-&gt;base |<br /> | i3c_master_do_daa(&amp;master-&gt;base)<br /> | //use master-&gt;base<br /> <br /> Fix it by ensuring that the work is canceled before proceeding with<br /> the cleanup in dw_i3c_common_remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: qcom: scm: Cleanup global &amp;#39;__scm&amp;#39; on probe failures<br /> <br /> If SCM driver fails the probe, it should not leave global &amp;#39;__scm&amp;#39;<br /> variable assigned, because external users of this driver will assume the<br /> probe finished successfully. For example TZMEM parts (&amp;#39;__scm-&gt;mempool&amp;#39;)<br /> are initialized later in the probe, but users of it (__scm_smc_call())<br /> rely on the &amp;#39;__scm&amp;#39; variable.<br /> <br /> This fixes theoretical NULL pointer exception, triggered via introducing<br /> probe deferral in SCM driver with call trace:<br /> <br /> qcom_tzmem_alloc+0x70/0x1ac (P)<br /> qcom_tzmem_alloc+0x64/0x1ac (L)<br /> qcom_scm_assign_mem+0x78/0x194<br /> qcom_rmtfs_mem_probe+0x2d4/0x38c<br /> platform_probe+0x68/0xc8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: state: fix out-of-bounds read during lookup<br /> <br /> lookup and resize can run in parallel.<br /> <br /> The xfrm_state_hash_generation seqlock ensures a retry, but the hash<br /> functions can observe a hmask value that is too large for the new hlist<br /> array.<br /> <br /> rehash does:<br /> rcu_assign_pointer(net-&gt;xfrm.state_bydst, ndst) [..]<br /> net-&gt;xfrm.state_hmask = nhashmask;<br /> <br /> While state lookup does:<br /> h = xfrm_dst_hash(net, daddr, saddr, tmpl-&gt;reqid, encap_family);<br /> hlist_for_each_entry_rcu(x, net-&gt;xfrm.state_bydst + h, bydst) {<br /> <br /> This is only safe in case the update to state_bydst is larger than<br /> net-&gt;xfrm.xfrm_state_hmask (or if the lookup function gets<br /> serialized via state spinlock again).<br /> <br /> Fix this by prefetching state_hmask and the associated pointers.<br /> The xfrm_state_hash_generation seqlock retry will ensure that the pointer<br /> and the hmask will be consistent.<br /> <br /> The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,<br /> add lockdep assertions to document that they are only safe for insert<br /> side.<br /> <br /> xfrm_state_lookup_byaddr() uses the spinlock rather than RCU.<br /> AFAICS this is an oversight from back when state lookup was converted to<br /> RCU, this lock should be replaced with RCU in a future patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: uvcvideo: Fix double free in error path<br /> <br /> If the uvc_status_init() function fails to allocate the int_urb, it will<br /> free the dev-&gt;status pointer but doesn&amp;#39;t reset the pointer to NULL. This<br /> results in the kfree() call in uvc_status_cleanup() trying to<br /> double-free the memory. Fix it by resetting the dev-&gt;status pointer to<br /> NULL after freeing it.<br /> <br /> Reviewed by: Ricardo Ribalda

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pps: Fix a use-after-free<br /> <br /> On a board running ntpd and gpsd, I&amp;#39;m seeing a consistent use-after-free<br /> in sys_exit() from gpsd when rebooting:<br /> <br /> pps pps1: removed<br /> ------------[ cut here ]------------<br /> kobject: &amp;#39;(null)&amp;#39; (00000000db4bec24): is not initialized, yet kobject_put() is being called.<br /> WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150<br /> CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1<br /> Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : kobject_put+0x120/0x150<br /> lr : kobject_put+0x120/0x150<br /> sp : ffffffc0803d3ae0<br /> x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001<br /> x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440<br /> x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600<br /> x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20<br /> x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000<br /> x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000<br /> x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000<br /> Call trace:<br /> kobject_put+0x120/0x150<br /> cdev_put+0x20/0x3c<br /> __fput+0x2c4/0x2d8<br /> ____fput+0x1c/0x38<br /> task_work_run+0x70/0xfc<br /> do_exit+0x2a0/0x924<br /> do_group_exit+0x34/0x90<br /> get_signal+0x7fc/0x8c0<br /> do_signal+0x128/0x13b4<br /> do_notify_resume+0xdc/0x160<br /> el0_svc+0xd4/0xf8<br /> el0t_64_sync_handler+0x140/0x14c<br /> el0t_64_sync+0x190/0x194<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> ...followed by more symptoms of corruption, with similar stacks:<br /> <br /> refcount_t: underflow; use-after-free.<br /> kernel BUG at lib/list_debug.c:62!<br /> Kernel panic - not syncing: Oops - BUG: Fatal exception<br /> <br /> This happens because pps_device_destruct() frees the pps_device with the<br /> embedded cdev immediately after calling cdev_del(), but, as the comment<br /> above cdev_del() notes, fops for previously opened cdevs are still<br /> callable even after cdev_del() returns. I think this bug has always<br /> been there: I can&amp;#39;t explain why it suddenly started happening every time<br /> I reboot this particular board.<br /> <br /> In commit d953e0e837e6 ("pps: Fix a use-after free bug when<br /> unregistering a source."), George Spelvin suggested removing the<br /> embedded cdev. That seems like the simplest way to fix this, so I&amp;#39;ve<br /> implemented his suggestion, using __register_chrdev() with pps_idr<br /> becoming the source of truth for which minor corresponds to which<br /> device.<br /> <br /> But now that pps_idr defines userspace visibility instead of cdev_add(),<br /> we need to be sure the pps-&gt;dev refcount can&amp;#39;t reach zero while<br /> userspace can still find it again. So, the idr_remove() call moves to<br /> pps_unregister_cdev(), and pps_idr now holds a reference to pps-&gt;dev.<br /> <br /> pps_core: source serial1 got cdev (251:1)<br /> <br /> pps pps1: removed<br /> pps_core: unregistering pps1<br /> pps_core: deallocating pps1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci: Fix NULL pointer dereference on certain command aborts<br /> <br /> If a command is queued to the final usable TRB of a ring segment, the<br /> enqueue pointer is advanced to the subsequent link TRB and no further.<br /> If the command is later aborted, when the abort completion is handled<br /> the dequeue pointer is advanced to the first TRB of the next segment.<br /> <br /> If no further commands are queued, xhci_handle_stopped_cmd_ring() sees<br /> the ring pointers unequal and assumes that there is a pending command,<br /> so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.<br /> <br /> Don&amp;#39;t attempt timer setup if cur_cmd is NULL. The subsequent doorbell<br /> ring likely is unnecessary too, but it&amp;#39;s harmless. Leave it alone.<br /> <br /> This is probably Bug 219532, but no confirmation has been received.<br /> <br /> The issue has been independently reproduced and confirmed fixed using<br /> a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.<br /> Everything continued working normally after several prevented crashes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtc: tps6594: Fix integer overflow on 32bit systems<br /> <br /> The problem is this multiply in tps6594_rtc_set_offset()<br /> <br /> tmp = offset * TICKS_PER_HOUR;<br /> <br /> The "tmp" variable is an s64 but "offset" is a long in the<br /> (-277774)-277774 range. On 32bit systems a long can hold numbers up to<br /> approximately two billion. The number of TICKS_PER_HOUR is really large,<br /> (32768 * 3600) or roughly a hundred million. When you start multiplying<br /> by a hundred million it doesn&amp;#39;t take long to overflow the two billion<br /> mark.<br /> <br /> Probably the safest way to fix this is to change the type of<br /> TICKS_PER_HOUR to long long because it&amp;#39;s such a large number.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp: Deal with race between UDP socket address change and rehash<br /> <br /> If a UDP socket changes its local address while it&amp;#39;s receiving<br /> datagrams, as a result of connect(), there is a period during which<br /> a lookup operation might fail to find it, after the address is changed<br /> but before the secondary hash (port and address) and the four-tuple<br /> hash (local and remote ports and addresses) are updated.<br /> <br /> Secondary hash chains were introduced by commit 30fff9231fad ("udp:<br /> bind() optimisation") and, as a result, a rehash operation became<br /> needed to make a bound socket reachable again after a connect().<br /> <br /> This operation was introduced by commit 719f835853a9 ("udp: add<br /> rehash on connect()") which isn&amp;#39;t however a complete fix: the<br /> socket will be found once the rehashing completes, but not while<br /> it&amp;#39;s pending.<br /> <br /> This is noticeable with a socat(1) server in UDP4-LISTEN mode, and a<br /> client sending datagrams to it. After the server receives the first<br /> datagram (cf. _xioopen_ipdgram_listen()), it issues a connect() to<br /> the address of the sender, in order to set up a directed flow.<br /> <br /> Now, if the client, running on a different CPU thread, happens to<br /> send a (subsequent) datagram while the server&amp;#39;s socket changes its<br /> address, but is not rehashed yet, this will result in a failed<br /> lookup and a port unreachable error delivered to the client, as<br /> apparent from the following reproducer:<br /> <br /> LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4))<br /> dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in<br /> <br /> while :; do<br /> taskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc &amp;<br /> sleep 0.1 || sleep 1<br /> taskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null<br /> wait<br /> done<br /> <br /> where the client will eventually get ECONNREFUSED on a write()<br /> (typically the second or third one of a given iteration):<br /> <br /> 2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection refused<br /> <br /> This issue was first observed as a seldom failure in Podman&amp;#39;s tests<br /> checking UDP functionality while using pasta(1) to connect the<br /> container&amp;#39;s network namespace, which leads us to a reproducer with<br /> the lookup error resulting in an ICMP packet on a tap device:<br /> <br /> LOCAL_ADDR="$(ip -j -4 addr show|jq -rM &amp;#39;.[] | .addr_info[0] | select(.scope == "global").local&amp;#39;)"<br /> <br /> while :; do<br /> ./pasta --config-net -p pasta.pcap -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc &amp;<br /> sleep 0.2 || sleep 1<br /> socat OPEN:tmp.in UDP4:${LOCAL_ADDR}:1337,shut-null<br /> wait<br /> cmp tmp.in tmp.out<br /> done<br /> <br /> Once this fails:<br /> <br /> tmp.in tmp.out differ: char 8193, line 29<br /> <br /> we can finally have a look at what&amp;#39;s going on:<br /> <br /> $ tshark -r pasta.pcap<br /> 1 0.000000 :: ? ff02::16 ICMPv6 110 Multicast Listener Report Message v2<br /> 2 0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192<br /> 3 0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192<br /> 4 0.168806 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192<br /> 5 0.168827 c6:47:05:8d:dc:04 ? Broadcast ARP 42 Who has 88.198.0.161? Tell 88.198.0.164<br /> 6 0.168851 9a:55:9a:55:9a:55 ? c6:47:05:8d:dc:04 ARP 42 88.198.0.161 is at 9a:55:9a:55:9a:55<br /> 7 0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192<br /> 8 0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable)<br /> 9 0.168926 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192<br /> 10 0.168959 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192<br /> 11 0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096<br /> 12 0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0<br /> <br /> On the third datagram received, the network namespace of the container<br /> initiates an ARP lookup to deliver the ICMP message.<br /> <br /> In another variant of this reproducer, starting the client with:<br /> <br /> strace -f pasta --config-net -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,tru<br /> ---truncated---