Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtk-sd: Prevent memory corruption from DMA map failure<br /> <br /> If msdc_prepare_data() fails to map the DMA region, the request is<br /> not prepared for data receiving, but msdc_start_data() proceeds<br /> the DMA with previous setting.<br /> Since this will lead a memory corruption, we have to stop the<br /> request operation soon after the msdc_prepare_data() fails to<br /> prepare it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-qpic-snand: reallocate BAM transactions<br /> <br /> Using the mtd_nandbiterrs module for testing the driver occasionally<br /> results in weird things like below.<br /> <br /> 1. swiotlb mapping fails with the following message:<br /> <br /> [ 85.926216] qcom_snand 79b0000.spi: swiotlb buffer is full (sz: 4294967294 bytes), total 512 (slots), used 0 (slots)<br /> [ 85.932937] qcom_snand 79b0000.spi: failure in mapping desc<br /> [ 87.999314] qcom_snand 79b0000.spi: failure to write raw page<br /> [ 87.999352] mtd_nandbiterrs: error: write_oob failed (-110)<br /> <br /> Rebooting the board after this causes a panic due to a NULL pointer<br /> dereference.<br /> <br /> 2. If the swiotlb mapping does not fail, rebooting the board may result<br /> in a different panic due to a bad spinlock magic:<br /> <br /> [ 256.104459] BUG: spinlock bad magic on CPU#3, procd/2241<br /> [ 256.104488] Unable to handle kernel paging request at virtual address ffffffff0000049b<br /> ...<br /> <br /> Investigating the issue revealed that these symptoms are results of<br /> memory corruption which is caused by out of bounds access within the<br /> driver.<br /> <br /> The driver uses a dynamically allocated structure for BAM transactions,<br /> which structure must have enough space for all possible variations of<br /> different flash operations initiated by the driver. The required space<br /> heavily depends on the actual number of &amp;#39;codewords&amp;#39; which is calculated<br /> from the pagesize of the actual NAND chip.<br /> <br /> Although the qcom_nandc_alloc() function allocates memory for the BAM<br /> transactions during probe, but since the actual number of &amp;#39;codewords&amp;#39;<br /> is not yet know the allocation is done for one &amp;#39;codeword&amp;#39; only.<br /> <br /> Because of this, whenever the driver does a flash operation, and the<br /> number of the required transactions exceeds the size of the allocated<br /> arrays the driver accesses memory out of the allocated range.<br /> <br /> To avoid this, change the code to free the initially allocated BAM<br /> transactions memory, and allocate a new one once the actual number of<br /> &amp;#39;codewords&amp;#39; required for a given NAND chip is known.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: return 0 size for RSS key if not supported<br /> <br /> Returning -EOPNOTSUPP from function returning u32 is leading to<br /> cast and invalid size value as a result.<br /> <br /> -EOPNOTSUPP as a size probably will lead to allocation fail.<br /> <br /> Command: ethtool -x eth0<br /> It is visible on all devices that don&amp;#39;t have RSS caps set.<br /> <br /> [ 136.615917] Call Trace:<br /> [ 136.615921] <br /> [ 136.615927] ? __warn+0x89/0x130<br /> [ 136.615942] ? __alloc_frozen_pages_noprof+0x322/0x330<br /> [ 136.615953] ? report_bug+0x164/0x190<br /> [ 136.615968] ? handle_bug+0x58/0x90<br /> [ 136.615979] ? exc_invalid_op+0x17/0x70<br /> [ 136.615987] ? asm_exc_invalid_op+0x1a/0x20<br /> [ 136.616001] ? rss_prepare_get.constprop.0+0xb9/0x170<br /> [ 136.616016] ? __alloc_frozen_pages_noprof+0x322/0x330<br /> [ 136.616028] __alloc_pages_noprof+0xe/0x20<br /> [ 136.616038] ___kmalloc_large_node+0x80/0x110<br /> [ 136.616072] __kmalloc_large_node_noprof+0x1d/0xa0<br /> [ 136.616081] __kmalloc_noprof+0x32c/0x4c0<br /> [ 136.616098] ? rss_prepare_get.constprop.0+0xb9/0x170<br /> [ 136.616105] rss_prepare_get.constprop.0+0xb9/0x170<br /> [ 136.616114] ethnl_default_doit+0x107/0x3d0<br /> [ 136.616131] genl_family_rcv_msg_doit+0x100/0x160<br /> [ 136.616147] genl_rcv_msg+0x1b8/0x2c0<br /> [ 136.616156] ? __pfx_ethnl_default_doit+0x10/0x10<br /> [ 136.616168] ? __pfx_genl_rcv_msg+0x10/0x10<br /> [ 136.616176] netlink_rcv_skb+0x58/0x110<br /> [ 136.616186] genl_rcv+0x28/0x40<br /> [ 136.616195] netlink_unicast+0x19b/0x290<br /> [ 136.616206] netlink_sendmsg+0x222/0x490<br /> [ 136.616215] __sys_sendto+0x1fd/0x210<br /> [ 136.616233] __x64_sys_sendto+0x24/0x30<br /> [ 136.616242] do_syscall_64+0x82/0x160<br /> [ 136.616252] ? __sys_recvmsg+0x83/0xe0<br /> [ 136.616265] ? syscall_exit_to_user_mode+0x10/0x210<br /> [ 136.616275] ? do_syscall_64+0x8e/0x160<br /> [ 136.616282] ? __count_memcg_events+0xa1/0x130<br /> [ 136.616295] ? count_memcg_events.constprop.0+0x1a/0x30<br /> [ 136.616306] ? handle_mm_fault+0xae/0x2d0<br /> [ 136.616319] ? do_user_addr_fault+0x379/0x670<br /> [ 136.616328] ? clear_bhb_loop+0x45/0xa0<br /> [ 136.616340] ? clear_bhb_loop+0x45/0xa0<br /> [ 136.616349] ? clear_bhb_loop+0x45/0xa0<br /> [ 136.616359] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 136.616369] RIP: 0033:0x7fd30ba7b047<br /> [ 136.616376] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d bd d5 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44<br /> [ 136.616381] RSP: 002b:00007ffde1796d68 EFLAGS: 00000202 ORIG_RAX: 000000000000002c<br /> [ 136.616388] RAX: ffffffffffffffda RBX: 000055d7bd89f2a0 RCX: 00007fd30ba7b047<br /> [ 136.616392] RDX: 0000000000000028 RSI: 000055d7bd89f3b0 RDI: 0000000000000003<br /> [ 136.616396] RBP: 00007ffde1796e10 R08: 00007fd30bb4e200 R09: 000000000000000c<br /> [ 136.616399] R10: 0000000000000000 R11: 0000000000000202 R12: 000055d7bd89f340<br /> [ 136.616403] R13: 000055d7bd89f3b0 R14: 000055d78943f200 R15: 0000000000000000

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-multipath: fix suspicious RCU usage warning<br /> <br /> When I run the NVME over TCP test in virtme-ng, I get the following<br /> "suspicious RCU usage" warning in nvme_mpath_add_sysfs_link():<br /> <br /> &amp;#39;&amp;#39;&amp;#39;<br /> [ 5.024557][ T44] nvmet: Created nvm controller 1 for subsystem nqn.2025-06.org.nvmexpress.mptcp for NQN nqn.2014-08.org.nvmexpress:uuid:f7f6b5e0-ff97-4894-98ac-c85309e0bc77.<br /> [ 5.027401][ T183] nvme nvme0: creating 2 I/O queues.<br /> [ 5.029017][ T183] nvme nvme0: mapped 2/0/0 default/read/poll queues.<br /> [ 5.032587][ T183] nvme nvme0: new ctrl: NQN "nqn.2025-06.org.nvmexpress.mptcp", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:f7f6b5e0-ff97-4894-98ac-c85309e0bc77<br /> [ 5.042214][ T25]<br /> [ 5.042440][ T25] =============================<br /> [ 5.042579][ T25] WARNING: suspicious RCU usage<br /> [ 5.042705][ T25] 6.16.0-rc3+ #23 Not tainted<br /> [ 5.042812][ T25] -----------------------------<br /> [ 5.042934][ T25] drivers/nvme/host/multipath.c:1203 RCU-list traversed in non-reader section!!<br /> [ 5.043111][ T25]<br /> [ 5.043111][ T25] other info that might help us debug this:<br /> [ 5.043111][ T25]<br /> [ 5.043341][ T25]<br /> [ 5.043341][ T25] rcu_scheduler_active = 2, debug_locks = 1<br /> [ 5.043502][ T25] 3 locks held by kworker/u9:0/25:<br /> [ 5.043615][ T25] #0: ffff888008730948 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x7ed/0x1350<br /> [ 5.043830][ T25] #1: ffffc900001afd40 ((work_completion)(&amp;entry-&gt;work)){+.+.}-{0:0}, at: process_one_work+0xcf3/0x1350<br /> [ 5.044084][ T25] #2: ffff888013ee0020 (&amp;head-&gt;srcu){.+.+}-{0:0}, at: nvme_mpath_add_sysfs_link.part.0+0xb4/0x3a0<br /> [ 5.044300][ T25]<br /> [ 5.044300][ T25] stack backtrace:<br /> [ 5.044439][ T25] CPU: 0 UID: 0 PID: 25 Comm: kworker/u9:0 Not tainted 6.16.0-rc3+ #23 PREEMPT(full)<br /> [ 5.044441][ T25] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> [ 5.044442][ T25] Workqueue: async async_run_entry_fn<br /> [ 5.044445][ T25] Call Trace:<br /> [ 5.044446][ T25] <br /> [ 5.044449][ T25] dump_stack_lvl+0x6f/0xb0<br /> [ 5.044453][ T25] lockdep_rcu_suspicious.cold+0x4f/0xb1<br /> [ 5.044457][ T25] nvme_mpath_add_sysfs_link.part.0+0x2fb/0x3a0<br /> [ 5.044459][ T25] ? queue_work_on+0x90/0xf0<br /> [ 5.044461][ T25] ? lockdep_hardirqs_on+0x78/0x110<br /> [ 5.044466][ T25] nvme_mpath_set_live+0x1e9/0x4f0<br /> [ 5.044470][ T25] nvme_mpath_add_disk+0x240/0x2f0<br /> [ 5.044472][ T25] ? __pfx_nvme_mpath_add_disk+0x10/0x10<br /> [ 5.044475][ T25] ? add_disk_fwnode+0x361/0x580<br /> [ 5.044480][ T25] nvme_alloc_ns+0x81c/0x17c0<br /> [ 5.044483][ T25] ? kasan_quarantine_put+0x104/0x240<br /> [ 5.044487][ T25] ? __pfx_nvme_alloc_ns+0x10/0x10<br /> [ 5.044495][ T25] ? __pfx_nvme_find_get_ns+0x10/0x10<br /> [ 5.044496][ T25] ? rcu_read_lock_any_held+0x45/0xa0<br /> [ 5.044498][ T25] ? validate_chain+0x232/0x4f0<br /> [ 5.044503][ T25] nvme_scan_ns+0x4c8/0x810<br /> [ 5.044506][ T25] ? __pfx_nvme_scan_ns+0x10/0x10<br /> [ 5.044508][ T25] ? find_held_lock+0x2b/0x80<br /> [ 5.044512][ T25] ? ktime_get+0x16d/0x220<br /> [ 5.044517][ T25] ? kvm_clock_get_cycles+0x18/0x30<br /> [ 5.044520][ T25] ? __pfx_nvme_scan_ns_async+0x10/0x10<br /> [ 5.044522][ T25] async_run_entry_fn+0x97/0x560<br /> [ 5.044523][ T25] ? rcu_is_watching+0x12/0xc0<br /> [ 5.044526][ T25] process_one_work+0xd3c/0x1350<br /> [ 5.044532][ T25] ? __pfx_process_one_work+0x10/0x10<br /> [ 5.044536][ T25] ? assign_work+0x16c/0x240<br /> [ 5.044539][ T25] worker_thread+0x4da/0xd50<br /> [ 5.044545][ T25] ? __pfx_worker_thread+0x10/0x10<br /> [ 5.044546][ T25] kthread+0x356/0x5c0<br /> [ 5.044548][ T25] ? __pfx_kthread+0x10/0x10<br /> [ 5.044549][ T25] ? ret_from_fork+0x1b/0x2e0<br /> [ 5.044552][ T25] ? __lock_release.isra.0+0x5d/0x180<br /> [ 5.044553][ T25] ? ret_from_fork+0x1b/0x2e0<br /> [ 5.044555][ T25] ? rcu_is_watching+0x12/0xc0<br /> [ 5.044557][ T25] ? __pfx_kthread+0x10/0x10<br /> [ 5.04<br /> ---truncated---

JHipster before v.8.9.0 allows privilege escalation via a modified authorities parameter. Upon registering in the JHipster portal and logging in as a standard user, the authorities parameter in the response from the api/account endpoint contains the value ROLE_USER. By manipulating the authorities parameter and changing its value to ROLE_ADMIN, the privilege is successfully escalated to an Admin level. This allowed the access to all admin-related functionalities in the application. NOTE: this is disputed by the Supplier because there is no privilege escalation in the context of the JHipster backend (the report only demonstrates that, after using JHipster to generate an application, one can make a non-functional admin screen visible in the front end of that application).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs: Clean up /proc/net/rpc/nfs when nfs_fs_proc_net_init() fails.<br /> <br /> syzbot reported a warning below [1] following a fault injection in<br /> nfs_fs_proc_net_init(). [0]<br /> <br /> When nfs_fs_proc_net_init() fails, /proc/net/rpc/nfs is not removed.<br /> <br /> Later, rpc_proc_exit() tries to remove /proc/net/rpc, and the warning<br /> is logged as the directory is not empty.<br /> <br /> Let&amp;#39;s handle the error of nfs_fs_proc_net_init() properly.<br /> <br /> [0]:<br /> FAULT_INJECTION: forcing a failure.<br /> name failslab, interval 1, probability 0, space 0, times 0<br /> CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:123)<br /> should_fail_ex (lib/fault-inject.c:73 lib/fault-inject.c:174)<br /> should_failslab (mm/failslab.c:46)<br /> kmem_cache_alloc_noprof (mm/slub.c:4178 mm/slub.c:4204)<br /> __proc_create (fs/proc/generic.c:427)<br /> proc_create_reg (fs/proc/generic.c:554)<br /> proc_create_net_data (fs/proc/proc_net.c:120)<br /> nfs_fs_proc_net_init (fs/nfs/client.c:1409)<br /> nfs_net_init (fs/nfs/inode.c:2600)<br /> ops_init (net/core/net_namespace.c:138)<br /> setup_net (net/core/net_namespace.c:443)<br /> copy_net_ns (net/core/net_namespace.c:576)<br /> create_new_namespaces (kernel/nsproxy.c:110)<br /> unshare_nsproxy_namespaces (kernel/nsproxy.c:218 (discriminator 4))<br /> ksys_unshare (kernel/fork.c:3123)<br /> __x64_sys_unshare (kernel/fork.c:3190)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> <br /> <br /> [1]:<br /> remove_proc_entry: removing non-empty directory &amp;#39;net/rpc&amp;#39;, leaking at least &amp;#39;nfs&amp;#39;<br /> WARNING: CPU: 1 PID: 6120 at fs/proc/generic.c:727 remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> RIP: 0010:remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727<br /> Code: 3c 02 00 0f 85 85 00 00 00 48 8b 93 d8 00 00 00 4d 89 f0 4c 89 e9 48 c7 c6 40 ba a2 8b 48 c7 c7 60 b9 a2 8b e8 33 81 1d ff 90 0b 90 90 e9 5f fe ff ff e8 04 69 5e ff 90 48 b8 00 00 00 00 00<br /> RSP: 0018:ffffc90003637b08 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: ffff88805f534140 RCX: ffffffff817a92c8<br /> RDX: ffff88807da99e00 RSI: ffffffff817a92d5 RDI: 0000000000000001<br /> RBP: ffff888033431ac0 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000001 R12: ffff888033431a00<br /> R13: ffff888033431ae4 R14: ffff888033184724 R15: dffffc0000000000<br /> FS: 0000555580328500(0000) GS:ffff888124a62000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f71733743e0 CR3: 000000007f618000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> sunrpc_exit_net+0x46/0x90 net/sunrpc/sunrpc_syms.c:76<br /> ops_exit_list net/core/net_namespace.c:200 [inline]<br /> ops_undo_list+0x2eb/0xab0 net/core/net_namespace.c:253<br /> setup_net+0x2e1/0x510 net/core/net_namespace.c:457<br /> copy_net_ns+0x2a6/0x5f0 net/core/net_namespace.c:574<br /> create_new_namespaces+0x3ea/0xa90 kernel/nsproxy.c:110<br /> unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:218<br /> ksys_unshare+0x45b/0xa40 kernel/fork.c:3121<br /> __do_sys_unshare kernel/fork.c:3192 [inline]<br /> __se_sys_unshare kernel/fork.c:3190 [inline]<br /> __x64_sys_unshare+0x31/0x40 kernel/fork.c:3190<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0x490 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fa1a6b8e929<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: altmodes/displayport: do not index invalid pin_assignments<br /> <br /> A poorly implemented DisplayPort Alt Mode port partner can indicate<br /> that its pin assignment capabilities are greater than the maximum<br /> value, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_show<br /> will cause a BRK exception due to an out of bounds array access.<br /> <br /> Prevent for loop in pin_assignment_show from accessing<br /> invalid values in pin_assignments by adding DP_PIN_ASSIGN_MAX<br /> value in typec_dp.h and using i

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods<br /> <br /> drvdata::gpiods is supposed to hold an array of &amp;#39;gpio_desc&amp;#39; pointers. But<br /> the memory is allocated for only one pointer. This will lead to<br /> out-of-bounds access later in the code if &amp;#39;config::ngpios&amp;#39; is &gt; 1. So<br /> fix the code to allocate enough memory to hold &amp;#39;config::ngpios&amp;#39; of GPIO<br /> descriptors.<br /> <br /> While at it, also move the check for memory allocation failure to be below<br /> the allocation to make it more readable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: appletb-kbd: fix memory corruption of input_handler_list<br /> <br /> In appletb_kbd_probe an input handler is initialised and then registered<br /> with input core through input_register_handler(). When this happens input<br /> core will add the input handler (specifically its node) to the global<br /> input_handler_list. The input_handler_list is central to the functionality<br /> of input core and is traversed in various places in input core. An example<br /> of this is when a new input device is plugged in and gets registered with<br /> input core.<br /> <br /> The input_handler in probe is allocated as device managed memory. If a<br /> probe failure occurs after input_register_handler() the input_handler<br /> memory is freed, yet it will remain in the input_handler_list. This<br /> effectively means the input_handler_list contains a dangling pointer<br /> to data belonging to a freed input handler.<br /> <br /> This causes an issue when any other input device is plugged in - in my<br /> case I had an old PixArt HP USB optical mouse and I decided to<br /> plug it in after a failure occurred after input_register_handler().<br /> This lead to the registration of this input device via<br /> input_register_device which involves traversing over every handler<br /> in the corrupted input_handler_list and calling input_attach_handler(),<br /> giving each handler a chance to bind to newly registered device.<br /> <br /> The core of this bug is a UAF which causes memory corruption of<br /> input_handler_list and to fix it we must ensure the input handler is<br /> unregistered from input core, this is done through<br /> input_unregister_handler().<br /> <br /> [ 63.191597] ==================================================================<br /> [ 63.192094] BUG: KASAN: slab-use-after-free in input_attach_handler.isra.0+0x1a9/0x1e0<br /> [ 63.192094] Read of size 8 at addr ffff888105ea7c80 by task kworker/0:2/54<br /> [ 63.192094]<br /> [ 63.192094] CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.16.0-rc2-00321-g2aa6621d<br /> [ 63.192094] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.164<br /> [ 63.192094] Workqueue: usb_hub_wq hub_event<br /> [ 63.192094] Call Trace:<br /> [ 63.192094] <br /> [ 63.192094] dump_stack_lvl+0x53/0x70<br /> [ 63.192094] print_report+0xce/0x670<br /> [ 63.192094] kasan_report+0xce/0x100<br /> [ 63.192094] input_attach_handler.isra.0+0x1a9/0x1e0<br /> [ 63.192094] input_register_device+0x76c/0xd00<br /> [ 63.192094] hidinput_connect+0x686d/0xad60<br /> [ 63.192094] hid_connect+0xf20/0x1b10<br /> [ 63.192094] hid_hw_start+0x83/0x100<br /> [ 63.192094] hid_device_probe+0x2d1/0x680<br /> [ 63.192094] really_probe+0x1c3/0x690<br /> [ 63.192094] __driver_probe_device+0x247/0x300<br /> [ 63.192094] driver_probe_device+0x49/0x210<br /> [ 63.192094] __device_attach_driver+0x160/0x320<br /> [ 63.192094] bus_for_each_drv+0x10f/0x190<br /> [ 63.192094] __device_attach+0x18e/0x370<br /> [ 63.192094] bus_probe_device+0x123/0x170<br /> [ 63.192094] device_add+0xd4d/0x1460<br /> [ 63.192094] hid_add_device+0x30b/0x910<br /> [ 63.192094] usbhid_probe+0x920/0xe00<br /> [ 63.192094] usb_probe_interface+0x363/0x9a0<br /> [ 63.192094] really_probe+0x1c3/0x690<br /> [ 63.192094] __driver_probe_device+0x247/0x300<br /> [ 63.192094] driver_probe_device+0x49/0x210<br /> [ 63.192094] __device_attach_driver+0x160/0x320<br /> [ 63.192094] bus_for_each_drv+0x10f/0x190<br /> [ 63.192094] __device_attach+0x18e/0x370<br /> [ 63.192094] bus_probe_device+0x123/0x170<br /> [ 63.192094] device_add+0xd4d/0x1460<br /> [ 63.192094] usb_set_configuration+0xd14/0x1880<br /> [ 63.192094] usb_generic_driver_probe+0x78/0xb0<br /> [ 63.192094] usb_probe_device+0xaa/0x2e0<br /> [ 63.192094] really_probe+0x1c3/0x690<br /> [ 63.192094] __driver_probe_device+0x247/0x300<br /> [ 63.192094] driver_probe_device+0x49/0x210<br /> [ 63.192094] __device_attach_driver+0x160/0x320<br /> [ 63.192094] bus_for_each_drv+0x10f/0x190<br /> [ 63.192094] __device_attach+0x18e/0x370<br /> [ 63.192094] bus_probe_device+0x123/0x170<br /> [ 63.192094] device_add+0xd4d/0x1460<br /> [ 63.192094] usb_new_device+0x7b4/0x1000<br /> [ 63.192094] hub_event+0x234d/0x3<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_ffa: Replace mutex with rwlock to avoid sleep in atomic context<br /> <br /> The current use of a mutex to protect the notifier hashtable accesses<br /> can lead to issues in the atomic context. It results in the below<br /> kernel warnings:<br /> <br /> | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258<br /> | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0<br /> | preempt_count: 1, expected: 0<br /> | RCU nest depth: 0, expected: 0<br /> | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0 #4<br /> | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn<br /> | Call trace:<br /> | show_stack+0x18/0x24 (C)<br /> | dump_stack_lvl+0x78/0x90<br /> | dump_stack+0x18/0x24<br /> | __might_resched+0x114/0x170<br /> | __might_sleep+0x48/0x98<br /> | mutex_lock+0x24/0x80<br /> | handle_notif_callbacks+0x54/0xe0<br /> | notif_get_and_handle+0x40/0x88<br /> | generic_exec_single+0x80/0xc0<br /> | smp_call_function_single+0xfc/0x1a0<br /> | notif_pcpu_irq_work_fn+0x2c/0x38<br /> | process_one_work+0x14c/0x2b4<br /> | worker_thread+0x2e4/0x3e0<br /> | kthread+0x13c/0x210<br /> | ret_from_fork+0x10/0x20<br /> <br /> To address this, replace the mutex with an rwlock to protect the notifier<br /> hashtable accesses. This ensures that read-side locking does not sleep and<br /> multiple readers can acquire the lock concurrently, avoiding unnecessary<br /> contention and potential deadlocks. Writer access remains exclusive,<br /> preserving correctness.<br /> <br /> This change resolves warnings from lockdep about potential sleep in<br /> atomic context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_ffa: Fix memory leak by freeing notifier callback node<br /> <br /> Commit e0573444edbf ("firmware: arm_ffa: Add interfaces to request<br /> notification callbacks") adds support for notifier callbacks by allocating<br /> and inserting a callback node into a hashtable during registration of<br /> notifiers. However, during unregistration, the code only removes the<br /> node from the hashtable without freeing the associated memory, resulting<br /> in a memory leak.<br /> <br /> Resolve the memory leak issue by ensuring the allocated notifier callback<br /> node is properly freed after it is removed from the hashtable entry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: convert control queue mutex to a spinlock<br /> <br /> With VIRTCHNL2_CAP_MACFILTER enabled, the following warning is generated<br /> on module load:<br /> <br /> [ 324.701677] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578<br /> [ 324.701684] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1582, name: NetworkManager<br /> [ 324.701689] preempt_count: 201, expected: 0<br /> [ 324.701693] RCU nest depth: 0, expected: 0<br /> [ 324.701697] 2 locks held by NetworkManager/1582:<br /> [ 324.701702] #0: ffffffff9f7be770 (rtnl_mutex){....}-{3:3}, at: rtnl_newlink+0x791/0x21e0<br /> [ 324.701730] #1: ff1100216c380368 (_xmit_ETHER){....}-{2:2}, at: __dev_open+0x3f0/0x870<br /> [ 324.701749] Preemption disabled at:<br /> [ 324.701752] [] __dev_open+0x3dd/0x870<br /> [ 324.701765] CPU: 30 UID: 0 PID: 1582 Comm: NetworkManager Not tainted 6.15.0-rc5+ #2 PREEMPT(voluntary)<br /> [ 324.701771] Hardware name: Intel Corporation M50FCP2SBSTD/M50FCP2SBSTD, BIOS SE5C741.86B.01.01.0001.2211140926 11/14/2022<br /> [ 324.701774] Call Trace:<br /> [ 324.701777] <br /> [ 324.701779] dump_stack_lvl+0x5d/0x80<br /> [ 324.701788] ? __dev_open+0x3dd/0x870<br /> [ 324.701793] __might_resched.cold+0x1ef/0x23d<br /> <br /> [ 324.701818] __mutex_lock+0x113/0x1b80<br /> <br /> [ 324.701917] idpf_ctlq_clean_sq+0xad/0x4b0 [idpf]<br /> [ 324.701935] ? kasan_save_track+0x14/0x30<br /> [ 324.701941] idpf_mb_clean+0x143/0x380 [idpf]<br /> <br /> [ 324.701991] idpf_send_mb_msg+0x111/0x720 [idpf]<br /> [ 324.702009] idpf_vc_xn_exec+0x4cc/0x990 [idpf]<br /> [ 324.702021] ? rcu_is_watching+0x12/0xc0<br /> [ 324.702035] idpf_add_del_mac_filters+0x3ed/0xb50 [idpf]<br /> <br /> [ 324.702122] __hw_addr_sync_dev+0x1cf/0x300<br /> [ 324.702126] ? find_held_lock+0x32/0x90<br /> [ 324.702134] idpf_set_rx_mode+0x317/0x390 [idpf]<br /> [ 324.702152] __dev_open+0x3f8/0x870<br /> [ 324.702159] ? __pfx___dev_open+0x10/0x10<br /> [ 324.702174] __dev_change_flags+0x443/0x650<br /> <br /> [ 324.702208] netif_change_flags+0x80/0x160<br /> [ 324.702218] do_setlink.isra.0+0x16a0/0x3960<br /> <br /> [ 324.702349] rtnl_newlink+0x12fd/0x21e0<br /> <br /> The sequence is as follows:<br /> rtnl_newlink()-&gt;<br /> __dev_change_flags()-&gt;<br /> __dev_open()-&gt;<br /> dev_set_rx_mode() - &gt; # disables BH and grabs "dev-&gt;addr_list_lock"<br /> idpf_set_rx_mode() -&gt; # proceed only if VIRTCHNL2_CAP_MACFILTER is ON<br /> __dev_uc_sync() -&gt;<br /> idpf_add_mac_filter -&gt;<br /> idpf_add_del_mac_filters -&gt;<br /> idpf_send_mb_msg() -&gt;<br /> idpf_mb_clean() -&gt;<br /> idpf_ctlq_clean_sq() # mutex_lock(cq_lock)<br /> <br /> Fix by converting cq_lock to a spinlock. All operations under the new<br /> lock are safe except freeing the DMA memory, which may use vunmap(). Fix<br /> by requesting a contiguous physical memory for the DMA mapping.