Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-49191 State: PUBLISHED Published: 2025-02-26T01:55:38.124Z Last Updated: 2025-05-04T08:31:56.809Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mxser: fix xmit_buf leak in activate when LSR == 0xff When LSR is 0xff in ->activate() (rather unlike), we return an error. Provided ->shutdown() is not called when ->activate() fails, nothing actually frees the buffer in this case. Fix this by properly freeing the buffer in a designated label. We jump there also from the "!info->type" if now too. References: - https://git.kernel.org/stable/c/376922045009f8ea2d20a8fa3475e95b47c41690 - https://git.kernel.org/stable/c/12
erences: - https://git.kernel.org/stable/c/376922045009f8ea2d20a8fa3475e95b47c41690 - https://git.kernel.org/stable/c/125b7c929fc9b1e5eaa344bceb6367dfa6fd3f9d - https://git.kernel.org/stable/c/685b6d16bf89595310b5d61394c9b97cc9505c7c - https://git.kernel.org/stable/c/996291d06851a26678a0fab488b6e1f0677c0576 - https://git.kernel.org/stable/c/2cd05c38a27bee7fb42aa4d43174d68ac55dac0f - https://git.kernel.org/stable/c/b125b08dbee3611f03f53b71471813ed4ccafcdd - https://git.kernel.org/stable/c/6c9041b2f90c0eace73106f22350e1d2c98f5edc - https://git.kernel.org/stable/c/6dffc2035fbaada60ca8db59e0962e34f760370a - https://git.kernel.org/stable/c/cd3a4907ee334b40d7aa880c7ab310b154fd5cd4
CVE ID: CVE-2022-49192 State: PUBLISHED Published: 2025-02-26T01:55:38.609Z Last Updated: 2025-05-04T08:31:58.822Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drivers: ethernet: cpsw: fix panic when interrupt coaleceing is set via ethtool cpsw_ethtool_begin directly returns the result of pm_runtime_get_sync when successful. pm_runtime_get_sync returns -error code on failure and 0 on successful resume but also 1 when the device is already active. So the common case for cpsw_ethtool_begin is to return 1. That leads to inconsistent calls to pm_runtime_put in the call-chain so that pm_runtime_put is called one too many times and
leads to inconsistent calls to pm_runtime_put in the call-chain so that pm_runtime_put is called one too many times and as result leaving the cpsw dev behind suspended. The suspended cpsw dev leads to an access violation later on by different parts of the cpsw driver. Fix this by calling the return-friendly pm_runtime_resume_and_get function. References: - https://git.kernel.org/stable/c/585dc196a08fccdcd1b7fcf473cf566b34c4b840 - https://git.kernel.org/stable/c/459080fab12b23c0526026e5cedbf3fabb5457cc - https://git.kernel.org/stable/c/30ad11bff021a94aff6dab1ec9236fdfd884fbff - https://git.kernel.org/stable/c/2844e2434385819f674d1fb4130c308c50ba681e
CVE ID: CVE-2022-49193 State: PUBLISHED Published: 2025-02-26T01:55:39.088Z Last Updated: 2025-05-04T08:32:05.116Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ice: fix 'scheduling while atomic' on aux critical err interrupt There's a kernel BUG splat on processing aux critical error interrupts in ice_misc_intr(): [ 2100.917085] BUG: scheduling while atomic: swapper/15/0/0x00010000 ... [ 2101.060770] Call Trace: [ 2101.063229] <IRQ> [ 2101.065252] dump_stack+0x41/0x60 [ 2101.068587] __schedule_bug.cold.100+0x4c/0x58 [ 2101.073060] __schedule+0x6a4/0x830 [ 2101.076570] schedule+0x35/0xa0 [ 2101.079727] schedule_preempt_disable
x4c/0x58 [ 2101.073060] __schedule+0x6a4/0x830 [ 2101.076570] schedule+0x35/0xa0 [ 2101.079727] schedule_preempt_disabled+0xa/0x10 [ 2101.084284] __mutex_lock.isra.7+0x310/0x420 [ 2101.088580] ? ice_misc_intr+0x201/0x2e0 [ice] [ 2101.093078] ice_send_event_to_aux+0x25/0x70 [ice] [ 2101.097921] ice_misc_intr+0x220/0x2e0 [ice] [ 2101.102232] __handle_irq_event_percpu+0x40/0x180 [ 2101.106965] handle_irq_event_percpu+0x30/0x80 [ 2101.111434] handle_irq_event+0x36/0x53 [ 2101.115292] handle_edge_irq+0x82/0x190 [ 2101.119148] handle_irq+0x1c/0x30 [ 2101.122480] do_IRQ+0x49/0xd0 [ 2101.125465] common_interrupt+0xf/0xf [ 2101.129146] </IRQ> ... As Andrew correctly mentioned previously[0], the follo
[ 2101.125465] common_interrupt+0xf/0xf [ 2101.129146] </IRQ> ... As Andrew correctly mentioned previously[0], the following call ladder happens: ice_misc_intr() <- hardirq ice_send_event_to_aux() device_lock() mutex_lock() might_sleep() might_resched() <- oops Add a new PF state bit which indicates that an aux critical error occurred and serve it in ice_service_task() in process context. The new ice_pf::oicr_err_reg is read-write in both hardirq and process contexts, but only 3 bits of non-critical data probably aren't worth explicit synchronizing (and they're even in the same byte [31:24]). [0] https://lore.kernel.org/all/YeSRUVmrdmlUXHDn@lunn.ch References: - https://git.kernel.org/stable
same byte [31:24]). [0] https://lore.kernel.org/all/YeSRUVmrdmlUXHDn@lunn.ch References: - https://git.kernel.org/stable/c/9b77c8cf69a41d1e3851370aeaa04a9ea83b865c - https://git.kernel.org/stable/c/24d7ac8426306ae7ccea7f7dd612a7368fe7201d - https://git.kernel.org/stable/c/59e88a50afad7469c55804e46bf2924b9130281f - https://git.kernel.org/stable/c/32d53c0aa3a7b727243473949bad2a830b908edc
CVE ID: CVE-2022-49194 State: PUBLISHED Published: 2025-02-26T01:55:39.581Z Last Updated: 2025-05-04T08:32:06.187Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: Use stronger register read/writes to assure ordering GCC12 appears to be much smarter about its dependency tracking and is aware that the relaxed variants are just normal loads and stores and this is causing problems like: [ 210.074549] ------------[ cut here ]------------ [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet): transmit queue 1 timed out [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240 [ 210.09
queue 1 timed out [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240 [ 210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat] [ 210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 5.17.0-rc7G12+ #58 [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters [ 210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022 [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS B
B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022 [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 210.161358] pc : dev_watchdog+0x234/0x240 [ 210.161364] lr : dev_watchdog+0x234/0x240 [ 210.161368] sp : ffff8000080a3a40 [ 210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [ 210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23: 0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19: ffff55b1426884c8 x18: ffffffffffffffff [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a [ 210.233831] x14: 2974656e65676d63 x13: ffffcd
26661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a [ 210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [ 210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c [ 210.248171] x8 : 00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000 [ 210.255341] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000001000 [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 : 0000000000000044 [ 210.269682] Call trace: [ 210.272133] dev_watchdog+0x234/0x240 [ 210.275811] call_timer_fn+0x3c/0x15c [ 210.279489] __run_timers.part.0+0x288/0x310 [ 210.283777] run_timer_softirq+0x48/0x80 [ 210.287716] __do_softirq+0x128/0x
10.279489] __run_timers.part.0+0x288/0x310 [ 210.283777] run_timer_softirq+0x48/0x80 [ 210.287716] __do_softirq+0x128/0x360 [ 210.291392] __irq_exit_rcu+0x138/0x140 [ 210.295243] irq_exit_rcu+0x1c/0x30 [ 210.298745] el1_interrupt+0x38/0x54 [ 210.302334] el1h_64_irq_handler+0x18/0x24 [ 210.306445] el1h_64_irq+0x7c/0x80 [ 210.309857] arch_cpu_idle+0x18/0x2c [ 210.313445] default_idle_call+0x4c/0x140 [ 210.317470] cpuidle_idle_call+0x14c/0x1a0 [ 210.321584] do_idle+0xb0/0x100 [ 210.324737] cpu_startup_entry+0x30/0x8c [ 210.328675] secondary_start_kernel+0xe4/0x110 [ 210.333138] __secondary_switched+0x94/0x98 The assumption when these were relaxed seems to be that device memory would be mapped n
] __secondary_switched+0x94/0x98 The assumption when these were relaxed seems to be that device memory would be mapped non reordering, and that other constructs (spinlocks/etc) would provide the barriers to assure that packet data and in memory rings/queues were ordered with respect to device register reads/writes. This itself seems a bit sketchy, but the real problem with GCC12 is that it is moving the actual reads/writes around at will as though they were independent operations when in truth they are not, but the compiler can't know that. When looking at the assembly dumps for many of these routines its possible to see very clean, but not strictly in program order operations occurring as t
s for many of these routines its possible to see very clean, but not strictly in program order operations occurring as the compiler would be free to do if these weren't actually register reads/write operations. Its possible to suppress the timeout with a liberal bit of dma_mb()'s sprinkled around but the device still seems unable to reliably send/receive data. A better plan is to use the safer readl/writel everywhere. Since this partially reverts an older commit, which notes the use of the relaxed variants for performance reasons. I would suggest that any performance problems ---truncated--- References: - https://git.kernel.org/stable/c/b26091a02093104259ca64aeca73601e56160d62 - https://git.
ms ---truncated--- References: - https://git.kernel.org/stable/c/b26091a02093104259ca64aeca73601e56160d62 - https://git.kernel.org/stable/c/06d836801cd82ded282aaf9e888ff9e7e4a88b91 - https://git.kernel.org/stable/c/1d717816189fd68f9e089cf89ed1f7327d2c2e71 - https://git.kernel.org/stable/c/f49769b462f282477ca801cf648f875b1c5b59db - https://git.kernel.org/stable/c/8d3ea3d402db94b61075617e71b67459a714a502
CVE ID: CVE-2022-49195 State: PUBLISHED Published: 2025-02-26T01:55:40.082Z Last Updated: 2025-05-04T08:32:07.310Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: dsa: fix panic on shutdown if multi-chip tree failed to probe DSA probing is atypical because a tree of devices must probe all at once, so out of N switches which call dsa_tree_setup_routing_table() during probe, for (N - 1) of them, "complete" will return false and they will exit probing early. The Nth switch will set up the whole tree on their behalf. The implication is that for (N - 1) switches, the driver binds to the device successfully, without doing anythin
behalf. The implication is that for (N - 1) switches, the driver binds to the device successfully, without doing anything. When the driver is bound, the ->shutdown() method may run. But if the Nth switch has failed to initialize the tree, there is nothing to do for the (N - 1) driver instances, since the slave devices have not been created, etc. Moreover, dsa_switch_shutdown() expects that the calling @ds has been in fact initialized, so it jumps at dereferencing the various data structures, which is incorrect. Avoid the ensuing NULL pointer dereferences by simply checking whether the Nth switch has previously set "ds->setup = true" for the switch which is currently shutting down. The entire
whether the Nth switch has previously set "ds->setup = true" for the switch which is currently shutting down. The entire setup is serialized under dsa2_mutex which we already hold. References: - https://git.kernel.org/stable/c/95df5cd5a446df6738d2d45872e08594819080e4 - https://git.kernel.org/stable/c/b6e668ff43ebd87ccc8a19e5481345c428672295 - https://git.kernel.org/stable/c/b864d5350c18bea9369d0bdd9e7eb6f6172cc283 - https://git.kernel.org/stable/c/8fd36358ce82382519b50b05f437493e1e00c4a9
CVE ID: CVE-2022-49196 State: PUBLISHED Published: 2025-02-26T01:55:40.626Z Last Updated: 2025-05-04T12:44:21.162Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix use after free in remove_phb_dynamic() In remove_phb_dynamic() we use &phb->io_resource, after we've called device_unregister(&host_bridge->dev). But the unregister may have freed phb, because pcibios_free_controller_deferred() is the release function for the host_bridge. If there are no outstanding references when we call device_unregister() then phb will be freed out from under us. This has gone mainly unnoticed, but with slub_debug and page_pois
unregister() then phb will be freed out from under us. This has gone mainly unnoticed, but with slub_debug and page_poison enabled it can lead to a crash: PID: 7574 TASK: c0000000d492cb80 CPU: 13 COMMAND: "drmgr" #0 [c0000000e4f075a0] crash_kexec at c00000000027d7dc #1 [c0000000e4f075d0] oops_end at c000000000029608 #2 [c0000000e4f07650] __bad_page_fault at c0000000000904b4 #3 [c0000000e4f076c0] do_bad_slb_fault at c00000000009a5a8 #4 [c0000000e4f076f0] data_access_slb_common_virt at c000000000008b30 Data SLB Access [380] exception frame: R0: c000000000167250 R1: c0000000e4f07a00 R2: c000000002a46100 R3: c000000002b39ce8 R4: 00000000000000c0 R5: 00000000000000a9 R6: 3894674d000000c0 R7: 0000
f07a00 R2: c000000002a46100 R3: c000000002b39ce8 R4: 00000000000000c0 R5: 00000000000000a9 R6: 3894674d000000c0 R7: 0000000000000000 R8: 00000000000000ff R9: 0000000000000100 R10: 6b6b6b6b6b6b6b6b R11: 0000000000008000 R12: c00000000023da80 R13: c0000009ffd38b00 R14: 0000000000000000 R15: 000000011c87f0f0 R16: 0000000000000006 R17: 0000000000000003 R18: 0000000000000002 R19: 0000000000000004 R20: 0000000000000005 R21: 000000011c87ede8 R22: 000000011c87c5a8 R23: 000000011c87d3a0 R24: 0000000000000000 R25: 0000000000000001 R26: c0000000e4f07cc8 R27: c00000004d1cc400 R28: c0080000031d00e8 R29: c00000004d23d800 R30: c00000004d1d2400 R31: c00000004d1d2540 NIP: c000000000167258 MSR: 80000000000090
0000031d00e8 R29: c00000004d23d800 R30: c00000004d1d2400 R31: c00000004d1d2540 NIP: c000000000167258 MSR: 8000000000009033 OR3: c000000000e9f474 CTR: 0000000000000000 LR: c000000000167250 XER: 0000000020040003 CCR: 0000000024088420 MQ: 0000000000000000 DAR: 6b6b6b6b6b6b6ba3 DSISR: c0000000e4f07920 Syscall Result: fffffffffffffff2 [NIP : release_resource+56] [LR : release_resource+48] #5 [c0000000e4f07a00] release_resource at c000000000167258 (unreliable) #6 [c0000000e4f07a30] remove_phb_dynamic at c000000000105648 #7 [c0000000e4f07ab0] dlpar_remove_slot at c0080000031a09e8 [rpadlpar_io] #8 [c0000000e4f07b50] remove_slot_store at c0080000031a0b9c [rpadlpar_io] #9 [c0000000e4f07be0] kobj_attr_
[rpadlpar_io] #8 [c0000000e4f07b50] remove_slot_store at c0080000031a0b9c [rpadlpar_io] #9 [c0000000e4f07be0] kobj_attr_store at c000000000817d8c #10 [c0000000e4f07c00] sysfs_kf_write at c00000000063e504 #11 [c0000000e4f07c20] kernfs_fop_write_iter at c00000000063d868 #12 [c0000000e4f07c70] new_sync_write at c00000000054339c #13 [c0000000e4f07d10] vfs_write at c000000000546624 #14 [c0000000e4f07d60] ksys_write at c0000000005469f4 #15 [c0000000e4f07db0] system_call_exception at c000000000030840 #16 [c0000000e4f07e10] system_call_vectored_common at c00000000000c168 To avoid it, we can take a reference to the host_bridge->dev until we're done using phb. Then when we drop the reference the phb w
t, we can take a reference to the host_bridge->dev until we're done using phb. Then when we drop the reference the phb will be freed. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/33d39efb61a84e055ca2386157d39ebbdf6b7d31 - https://git.kernel.org/stable/c/403f9e0bc5535a0a5184d1352fa3a70e6ffacb6f - https://git.kernel.org/stable/c/895ca4ae1f72e0a0160ab162723e59c9f265ec93 - https://git.kernel.org/stable/c/fe2640bd7a62f1f7c3f55fbda31084085075bc30
CVE ID: CVE-2022-49197 State: PUBLISHED Published: 2025-02-26T01:55:41.112Z Last Updated: 2025-05-04T08:32:09.798Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: af_netlink: Fix shift out of bounds in group mask calculation When a netlink message is received, netlink_recvmsg() fills in the address of the sender. One of the fields is the 32-bit bitfield nl_groups, which carries the multicast group on which the message was received. The least significant bit corresponds to group 1, and therefore the highest group that the field can represent is 32. Above that, the UB sanitizer flags the out-of-bounds shift attempts. Which bits en
p that the field can represent is 32. Above that, the UB sanitizer flags the out-of-bounds shift attempts. Which bits end up being set in such case is implementation defined, but it's either going to be a wrong non-zero value, or zero, which is at least not misleading. Make the latter choice deterministic by always setting to 0 for higher-numbered multicast groups. To get information about membership in groups >= 32, userspace is expected to use nl_pktinfo control messages[0], which are enabled by NETLINK_PKTINFO socket option. [0] https://lwn.net/Articles/147608/ The way to trigger this issue is e.g. through monitoring the BRVLAN group: # bridge monitor vlan & # ip link add name br type bri
o trigger this issue is e.g. through monitoring the BRVLAN group: # bridge monitor vlan & # ip link add name br type bridge Which produces the following citation: UBSAN: shift-out-of-bounds in net/netlink/af_netlink.c:162:19 shift exponent 32 is too large for 32-bit type 'int' References: - https://git.kernel.org/stable/c/e1c5d46f05aa23d740daae5cd3a6472145afac42 - https://git.kernel.org/stable/c/ac5883a8890a11c00b32a19949a25d4afeaa2f5a - https://git.kernel.org/stable/c/f75f4abeec4c04b600a15b50c89a481f1e7435ee - https://git.kernel.org/stable/c/41249fff507387c3323b198d0052faed08b14de4 - https://git.kernel.org/stable/c/b0898362188e05b2202656058cc32d98fabf3bac - https://git.kernel.org/stable/c/7
d08b14de4 - https://git.kernel.org/stable/c/b0898362188e05b2202656058cc32d98fabf3bac - https://git.kernel.org/stable/c/7409ff6393a67ff9838d0ae1bd102fb5f020d07a - https://git.kernel.org/stable/c/e8aaf3134bc5e943048eefe9f2ddaabf41d92b1a - https://git.kernel.org/stable/c/e23e1e981247feb3c7d0236fe58aceb685f234ae - https://git.kernel.org/stable/c/0caf6d9922192dd1afa8dc2131abfb4df1443b9f
CVE ID: CVE-2022-49198 State: PUBLISHED Published: 2025-02-26T01:55:41.631Z Last Updated: 2025-05-04T08:32:10.900Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix crash due to tcp_tsorted_anchor was initialized before release skb Got crash when doing pressure test of mptcp: =========================================================================== dst_release: dst:ffffa06ce6e5c058 refcnt:-1 kernel tried to execute NX-protected page - exploit attempt? (uid: 0) BUG: unable to handle kernel paging request at ffffa06ce6e5c058 PGD 190a01067 P4D 190a01067 PUD 43fffb067 PMD 22e403063 PTE 8000000226e5c063 Oops: 0011 [#1] SMP
est at ffffa06ce6e5c058 PGD 190a01067 P4D 190a01067 PUD 43fffb067 PMD 22e403063 PTE 8000000226e5c063 Oops: 0011 [#1] SMP PTI CPU: 7 PID: 7823 Comm: kworker/7:0 Kdump: loaded Tainted: G E Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.2.1 04/01/2014 Call Trace: ? skb_release_head_state+0x68/0x100 ? skb_release_all+0xe/0x30 ? kfree_skb+0x32/0xa0 ? mptcp_sendmsg_frag+0x57e/0x750 ? __mptcp_retrans+0x21b/0x3c0 ? __switch_to_asm+0x35/0x70 ? mptcp_worker+0x25e/0x320 ? process_one_work+0x1a7/0x360 ? worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 ? kthread+0x112/0x130 ? kthread_flush_work_fn+0x10/0x10 ? ret_from_fork+0x35/0x40 =====================================================
/0x130 ? kthread_flush_work_fn+0x10/0x10 ? ret_from_fork+0x35/0x40 =========================================================================== In __mptcp_alloc_tx_skb skb was allocated and skb->tcp_tsorted_anchor will be initialized, in under memory pressure situation sk_wmem_schedule will return false and then kfree_skb. In this case skb->_skb_refdst is not null because_skb_refdst and tcp_tsorted_anchor are stored in the same mem, and kfree_skb will try to release dst and cause crash. References: - https://git.kernel.org/stable/c/af61a8f7603926c26158153d0a0755764d82657c - https://git.kernel.org/stable/c/752add6f5ce5305e55d8bda4ac8d69be3a09f14d - https://git.kernel.org/stable/c/4d54181eba4b0
https://git.kernel.org/stable/c/752add6f5ce5305e55d8bda4ac8d69be3a09f14d - https://git.kernel.org/stable/c/4d54181eba4b077fb74033a7186898ad4000a7a5 - https://git.kernel.org/stable/c/3ef3905aa3b5b3e222ee6eb0210bfd999417a8cc
CVE ID: CVE-2022-49199 State: PUBLISHED Published: 2025-02-26T01:55:42.120Z Last Updated: 2025-05-04T08:32:12.066Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/nldev: Prevent underflow in nldev_stat_set_counter_dynamic_doit() This code checks "index" for an upper bound but it does not check for negatives. Change the type to unsigned to prevent underflows. References: - https://git.kernel.org/stable/c/f6dd8669b8299a3a536cd92a7069152a7704da1d - https://git.kernel.org/stable/c/2a495ef04d5f42e6f00eb2bec1ee9075e3d5a771 - https://git.kernel.org/stable/c/87e0eacb176f9500c2063d140c0a1d7fa51ab8a5
CVE ID: CVE-2022-49200 State: PUBLISHED Published: 2025-02-26T01:55:42.758Z Last Updated: 2025-05-04T08:32:13.272Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtksdio: Fix kernel oops in btmtksdio_interrupt Fix the following kernel oops in btmtksdio_interrrupt [ 14.339134] btmtksdio_interrupt+0x28/0x54 [ 14.339139] process_sdio_pending_irqs+0x68/0x1a0 [ 14.339144] sdio_irq_work+0x40/0x70 [ 14.339154] process_one_work+0x184/0x39c [ 14.339160] worker_thread+0x228/0x3e8 [ 14.339168] kthread+0x148/0x3ac [ 14.339176] ret_from_fork+0x10/0x30 That happened because hdev->power_on is already called before sdio_set_drvdat
0x3ac [ 14.339176] ret_from_fork+0x10/0x30 That happened because hdev->power_on is already called before sdio_set_drvdata which btmtksdio_interrupt handler relies on is not properly set up. The details are shown as the below: hci_register_dev would run queue_work(hdev->req_workqueue, &hdev->power_on) as WQ_HIGHPRI workqueue_struct to complete the power-on sequeunce and thus hci_power_on may run before sdio_set_drvdata is done in btmtksdio_probe. The hci_dev_do_open in hci_power_on would initialize the device and enable the interrupt and thus it is possible that btmtksdio_interrupt is being called right before sdio_set_drvdata is filled out. When btmtksdio_interrupt is being called and sdio_s
terrupt is being called right before sdio_set_drvdata is filled out. When btmtksdio_interrupt is being called and sdio_set_drvdata is not filled , the kernel oops is going to happen because btmtksdio_interrupt access an uninitialized pointer. References: - https://git.kernel.org/stable/c/874eca93966a786eace87fa6dfb206c2dd9519b1 - https://git.kernel.org/stable/c/70a6cf749d9ff9f463490248322e5343199bc267 - https://git.kernel.org/stable/c/770a97d3f34b801de1b04737b43e02c55118c41a - https://git.kernel.org/stable/c/4d3d1f2c35a19988d3c5f0ee86038b525e830840 - https://git.kernel.org/stable/c/6d7be5afbb41c918d2f12f857f8c7efa50500be2 - https://git.kernel.org/stable/c/b062a0b9c1dc1ff63094337dccfe1568d5b6
stable/c/6d7be5afbb41c918d2f12f857f8c7efa50500be2 - https://git.kernel.org/stable/c/b062a0b9c1dc1ff63094337dccfe1568d5b62023