Page 173 of 1286 results (0.007 seconds)

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ionic: use dev_consume_skb_any outside of napi If we're not in a NAPI softirq context, we need to be careful about how we call napi_consume_skb(), specifically we need to call it with budget==0 to signal to it that we're not in a safe context. This was found while running some configuration stress testing of traffic and a change queue config loop running, and this curious note popped out: [ 4371.402645] BUG: using smp_processor_id() in preemptible [00000000] code: ethtool/20545 [ 4371.402897] caller is napi_skb_cache_put+0x16/0x80 [ 4371.403120] CPU: 25 PID: 20545 Comm: ethtool Kdump: loaded Tainted: G OE 6.10.0-rc3-netnext+ #8 [ 4371.403302] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 01/23/2021 [ 4371.403460] Call Trace: [ 4371.403613] <TASK> [ 4371.403758] dump_stack_lvl+0x4f/0x70 [ 4371.403904] check_preemption_disabled+0xc1/0xe0 [ 4371.404051] napi_skb_cache_put+0x16/0x80 [ 4371.404199] ionic_tx_clean+0x18a/0x240 [ionic] [ 4371.404354] ionic_tx_cq_service+0xc4/0x200 [ionic] [ 4371.404505] ionic_tx_flush+0x15/0x70 [ionic] [ 4371.404653] ? ionic_lif_qcq_deinit.isra.23+0x5b/0x70 [ionic] [ 4371.404805] ionic_txrx_deinit+0x71/0x190 [ionic] [ 4371.404956] ionic_reconfigure_queues+0x5f5/0xff0 [ionic] [ 4371.405111] ionic_set_ringparam+0x2e8/0x3e0 [ionic] [ 4371.405265] ethnl_set_rings+0x1f1/0x300 [ 4371.405418] ethnl_default_set_doit+0xbb/0x160 [ 4371.405571] genl_family_rcv_msg_doit+0xff/0x130 [...] I found that ionic_tx_clean() calls napi_consume_skb() which calls napi_skb_cache_put(), but before that last call is the note /* Zero budget indicate non-NAPI context called us, like netpoll */ and DEBUG_NET_WARN_ON_ONCE(!in_softirq()); Those are pretty big hints that we're doing it wrong. We can pass a context hint down through the calls to let ionic_tx_clean() know what we're doing so it can call napi_consume_skb() correctly. • https://git.kernel.org/stable/c/386e69865311044b576ff536c99c6ee9cc98a228 https://git.kernel.org/stable/c/ef7646ed49fff962e97b276f4ab91327a67eeb5a https://git.kernel.org/stable/c/84b767f9e34fdb143c09e66a2a20722fc2921821 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers register store validation for NFT_DATA_VALUE is conditional, however, the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This only requires a new helper function to infer the register type from the set datatype so this conditional check can be removed. Otherwise, pointer to chain object can be leaked through the registers. • https://git.kernel.org/stable/c/96518518cc417bb0a8c80b9fb736202e28acdf96 https://git.kernel.org/stable/c/40188a25a9847dbeb7ec67517174a835a677752f https://git.kernel.org/stable/c/23752737c6a618e994f9a310ec2568881a6b49c4 https://git.kernel.org/stable/c/5d43d789b57943720dca4181a05f6477362b94cf https://git.kernel.org/stable/c/461302e07f49687ffe7d105fa0a330c07c7646d8 https://git.kernel.org/stable/c/efb27ad05949403848f487823b597ed67060e007 https://git.kernel.org/stable/c/952bf8df222599baadbd4f838a49c4fef81d2564 https://git.kernel.org/stable/c/41a6375d48deaf7f730304b5153848bfa •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix possible double free in error handling path When auxiliary_device_add() returns error and then calls auxiliary_device_uninit(), callback function adev_release calls kfree(madev). We shouldn't call kfree(madev) again in the error handling path. Set 'madev' to NULL. • https://git.kernel.org/stable/c/a69839d4327d053b18d8e1b0e7ddeee78db78f4f https://git.kernel.org/stable/c/3243e64eb4d897c3eeb48b2a7221ab5a95e1282a https://git.kernel.org/stable/c/ed45c0a0b662079d4c0e518014cc148c753979b4 https://git.kernel.org/stable/c/1864b8224195d0e43ddb92a8151f54f6562090cc •

CVSS: -EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro() set_memory_ro() can fail, leaving memory unprotected. Check its return and take it into account as an error. • https://git.kernel.org/stable/c/a359696856ca9409fb97655c5a8ef0f549cb6e03 https://git.kernel.org/stable/c/e4f602e3ff749ba770bf8ff10196e18358de6720 https://git.kernel.org/stable/c/fdd411af8178edc6b7bf260f8fa4fba1bedd0a6d https://git.kernel.org/stable/c/e3540e5a7054d6daaf9a1415a48aacb092112a89 https://git.kernel.org/stable/c/05412471beba313ecded95aa17b25fe84bb2551a https://git.kernel.org/stable/c/7d2cc63eca0c993c99d18893214abf8f85d566d8 •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro() set_memory_rox() can fail, leaving memory unprotected. Check return and bail out when bpf_jit_binary_lock_ro() returns an error. • https://git.kernel.org/stable/c/08f6c05feb1db21653e98ca84ea04ca032d014c7 https://git.kernel.org/stable/c/9fef36cad60d4226f9d06953cd56d1d2f9119730 https://git.kernel.org/stable/c/044da7ae7afd4ef60806d73654a2e6a79aa4ed7a https://git.kernel.org/stable/c/e60adf513275c3a38e5cb67f7fd12387e43a3ff5 •