Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
761af41533d8d1d6eb4543b0 - https://git.kernel.org/stable/c/0581613df7f9a4c5fac096ce1d5fb15b7b994240 - https://git.kernel.org/stable/c/1807d8867402a58b831a7fc16832747ff559a0d1 - https://git.kernel.org/stable/c/f036392edd9c49090781d8cca26ad6557a63bae4 - https://git.kernel.org/stable/c/9fc33eaaa979d112d10fea729edcd2a2e21aa912
CVE ID: CVE-2022-49646 State: PUBLISHED Published: 2025-02-26T02:23:51.083Z Last Updated: 2025-06-19T12:56:22.868Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix queue selection for mesh/OCB interfaces When using iTXQ, the code assumes that there is only one vif queue for broadcast packets, using the BE queue. Allowing non-BE queue marking violates that assumption and txq->ac == skb_queue_mapping is no longer guaranteed. This can cause issues with queue handling in the driver and also causes issues with the recent ATF change, resulting in an AQL underflow warning. References: - https://git.kernel.org/stable/
s issues with the recent ATF change, resulting in an AQL underflow warning. References: - https://git.kernel.org/stable/c/444be5a02b77f3b7a8ac9c1a0b074fbb3bd89cd0 - https://git.kernel.org/stable/c/e013ea2a51a94b903b396a8dff531a07d470335d - https://git.kernel.org/stable/c/5a9df31017999197b6e60535940f2f2fe1bd3b0d - https://git.kernel.org/stable/c/41ecab279a70dced9005f4d55fa0fcde8938603f - https://git.kernel.org/stable/c/50e2ab39291947b6c6c7025cf01707c270fcde59
CVE ID: CVE-2022-49647 State: PUBLISHED Published: 2025-02-26T02:23:51.561Z Last Updated: 2025-05-04T08:42:31.208Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cgroup: Use separate src/dst nodes when preloading css_sets for migration Each cset (css_set) is pinned by its tasks. When we're moving tasks around across csets for a migration, we need to hold the source and destination csets to ensure that they don't go away while we're moving tasks about. This is done by linking cset->mg_preload_node on either the mgctx->preloaded_src_csets or mgctx->preloaded_dst_csets list. Using the same cset->mg_preload_node for both the src an
mgctx->preloaded_src_csets or mgctx->preloaded_dst_csets list. Using the same cset->mg_preload_node for both the src and dst lists was deemed okay as a cset can't be both the source and destination at the same time. Unfortunately, this overloading becomes problematic when multiple tasks are involved in a migration and some of them are identity noop migrations while others are actually moving across cgroups. For example, this can happen with the following sequence on cgroup1: #1> mkdir -p /sys/fs/cgroup/misc/a/b #2> echo $$ > /sys/fs/cgroup/misc/a/cgroup.procs #3> RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS & #4> PID=$! #5> echo $PID > /sys/fs/cgroup/misc/a/b/tasks #6> echo $PID > /sys/fs/c
MAND_WHICH_CREATES_MULTIPLE_THREADS & #4> PID=$! #5> echo $PID > /sys/fs/cgroup/misc/a/b/tasks #6> echo $PID > /sys/fs/cgroup/misc/a/cgroup.procs the process including the group leader back into a. In this final migration, non-leader threads would be doing identity migration while the group leader is doing an actual one. After #3, let's say the whole process was in cset A, and that after #4, the leader moves to cset B. Then, during #6, the following happens: 1. cgroup_migrate_add_src() is called on B for the leader. 2. cgroup_migrate_add_src() is called on A for the other threads. 3. cgroup_migrate_prepare_dst() is called. It scans the src list. 4. It notices that B wants to migrate to A, so
hreads. 3. cgroup_migrate_prepare_dst() is called. It scans the src list. 4. It notices that B wants to migrate to A, so it tries to A to the dst list but realizes that its ->mg_preload_node is already busy. 5. and then it notices A wants to migrate to A as it's an identity migration, it culls it by list_del_init()'ing its ->mg_preload_node and putting references accordingly. 6. The rest of migration takes place with B on the src list but nothing on the dst list. This means that A isn't held while migration is in progress. If all tasks leave A before the migration finishes and the incoming task pins it, the cset will be destroyed leading to use-after-free. This is caused by overloading cset-
and the incoming task pins it, the cset will be destroyed leading to use-after-free. This is caused by overloading cset->mg_preload_node for both src and dst preload lists. We wanted to exclude the cset from the src list but ended up inadvertently excluding it from the dst list too. This patch fixes the issue by separating out cset->mg_preload_node into ->mg_src_preload_node and ->mg_dst_preload_node, so that the src and dst preloadings don't interfere with each other. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/05f7658210d1d331e8dd4cb6e7bbbe3df5f5ac27 - https://git.kernel.org/stable/c/cec2bbdcc14fbaa6b95ee15a7c423b05d97038be - https://git
0d1d331e8dd4cb6e7bbbe3df5f5ac27 - https://git.kernel.org/stable/c/cec2bbdcc14fbaa6b95ee15a7c423b05d97038be - https://git.kernel.org/stable/c/ad44e05f3e016bdcb1ad25af35ade5b5f41ccd68 - https://git.kernel.org/stable/c/7657e3958535d101a24ab4400f9b8062b9107cc4 - https://git.kernel.org/stable/c/54aee4e5ce8c21555286a6333e46c1713880cf93 - https://git.kernel.org/stable/c/0e41774b564befa6d271e8d5086bf870d617a4e6 - https://git.kernel.org/stable/c/07fd5b6cdf3cc30bfde8fe0f644771688be04447
CVE ID: CVE-2022-49648 State: PUBLISHED Published: 2025-02-26T02:23:52.035Z Last Updated: 2025-10-01T19:36:48.613Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing/histograms: Fix memory leak problem This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. As commit 46bbe5c671e0 ("tracing: fix double free") said, the "double free" problem reported by clang static analyzer is: > In parse_var_defs() if there is a problem allocating > var_defs.expr, the earlier var_defs.name is freed. > This free is duplicated by free_var_defs() which frees > the rest of the list. However, if there is a problem allocating N-th var_defs.
plicated by free_var_defs() which frees > the rest of the list. However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed 'earlier var_defs.name' is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed; IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+----------- These two frees don't act on same name, so there was no "double free" problem before. Conversely, after that commit, we get a "memory leak" problem b
same name, so there was no "double free" problem before. Conversely, after that commit, we get a "memory leak" problem because the above "N-th var_defs.name" is not freed. If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocated, then execute on shell like: $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm "bash", pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_pars
0 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0 [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110 [<0000000066737a4c>] event_trigger_write+0x75/0xd0 [<000000007341e40c>] vfs_write+0xbb/0x2a0 [<0000000087fde4c2>] ksys_write+0x59/0xd0 [<00000000581e9cdf>] do_syscall_64+0x3a/0x80 [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/eb622d5580b9e2ff694f62da6410618bd73853cb - https://git.kernel.org/stable/c/ecc6dec12c33aa92c086cd702af9f544ddaf3c75 - https://git.kernel.org/stable/c/78a1400c42ee11197eb1f
git.kernel.org/stable/c/ecc6dec12c33aa92c086cd702af9f544ddaf3c75 - https://git.kernel.org/stable/c/78a1400c42ee11197eb1f0f85ba51df9a4fdfff0 - https://git.kernel.org/stable/c/22eeff55679d9e7c0f768c79bfbd83e2f8142d89 - https://git.kernel.org/stable/c/4d453eb5e1eec89971aa5b3262857ee26cfdffd3 - https://git.kernel.org/stable/c/7edc3945bdce9c39198a10d6129377a5c53559c2
CVE ID: CVE-2022-49649 State: PUBLISHED Published: 2025-02-26T02:23:52.531Z Last Updated: 2025-10-01T19:36:48.488Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xen/netback: avoid entering xenvif_rx_next_skb() with an empty rx queue xenvif_rx_next_skb() is expecting the rx queue not being empty, but in case the loop in xenvif_rx_action() is doing multiple iterations, the availability of another skb in the rx queue is not being checked. This can lead to crashes: [40072.537261] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 [40072.537407] IP: xenvif_rx_skb+0x23/0x590 [xen_netback] [40072.537534] PGD 0
pointer dereference at 0000000000000080 [40072.537407] IP: xenvif_rx_skb+0x23/0x590 [xen_netback] [40072.537534] PGD 0 P4D 0 [40072.537644] Oops: 0000 [#1] SMP NOPTI [40072.537749] CPU: 0 PID: 12505 Comm: v1-c40247-q2-gu Not tainted 4.12.14-122.121-default #1 SLE12-SP5 [40072.537867] Hardware name: HP ProLiant DL580 Gen9/ProLiant DL580 Gen9, BIOS U17 11/23/2021 [40072.537999] task: ffff880433b38100 task.stack: ffffc90043d40000 [40072.538112] RIP: e030:xenvif_rx_skb+0x23/0x590 [xen_netback] [40072.538217] RSP: e02b:ffffc90043d43de0 EFLAGS: 00010246 [40072.538319] RAX: 0000000000000000 RBX: ffffc90043cd7cd0 RCX: 00000000000000f7 [40072.538430] RDX: 0000000000000000 RSI: 0000000000000006 RDI:
00000000000 RBX: ffffc90043cd7cd0 RCX: 00000000000000f7 [40072.538430] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffffc90043d43df8 [40072.538531] RBP: 000000000000003f R08: 000077ff80000000 R09: 0000000000000008 [40072.538644] R10: 0000000000007ff0 R11: 00000000000008f6 R12: ffffc90043ce2708 [40072.538745] R13: 0000000000000000 R14: ffffc90043d43ed0 R15: ffff88043ea748c0 [40072.538861] FS: 0000000000000000(0000) GS:ffff880484600000(0000) knlGS:0000000000000000 [40072.538988] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [40072.539088] CR2: 0000000000000080 CR3: 0000000407ac8000 CR4: 0000000000040660 [40072.539211] Call Trace: [40072.539319] xenvif_rx_action+0x71/0x90 [xen_netback] [
0000407ac8000 CR4: 0000000000040660 [40072.539211] Call Trace: [40072.539319] xenvif_rx_action+0x71/0x90 [xen_netback] [40072.539429] xenvif_kthread_guest_rx+0x14a/0x29c [xen_netback] Fix that by stopping the loop in case the rx queue becomes empty. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/c0fcceb5f3f1ec197c014fe218c2f28108cacd27 - https://git.kernel.org/stable/c/d5320c6a27aa975aff740f9cb481dcbde48f4348 - https://git.kernel.org/stable/c/5a071aefd6414af5a20321ab58a0557b81993687 - https://git.kernel.org/stable/c/7425479d20f9e96f7c3ec8e8a93fe0d7478724cb - https://git.kernel.org/stable/c/b9c32a6886af79d6e0ad87a7b01800ed079cdd02 - https://gi
20f9e96f7c3ec8e8a93fe0d7478724cb - https://git.kernel.org/stable/c/b9c32a6886af79d6e0ad87a7b01800ed079cdd02 - https://git.kernel.org/stable/c/b99174ac57fe5d8867448c03b23828e63f24cb1c - https://git.kernel.org/stable/c/f0b5c819b062df8bf5f2acf4697e3871cb3722da - https://git.kernel.org/stable/c/94e8100678889ab428e68acadf042de723f094b9
CVE ID: CVE-2022-49650 State: PUBLISHED Published: 2025-02-26T02:23:53.006Z Last Updated: 2025-05-04T08:42:34.836Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom: bam_dma: fix runtime PM underflow Commit dbad41e7bb5f ("dmaengine: qcom: bam_dma: check if the runtime pm enabled") caused unbalanced pm_runtime_get/put() calls when the bam is controlled remotely. This commit reverts it and just enables pm_runtime in all cases, the clk_* functions already just nop when the clock is NULL. Also clean up a bit by removing unnecessary bamclk null checks. References: - https://git.kernel.org/stable/c/2f6ded79068cac8cff41d5
p a bit by removing unnecessary bamclk null checks. References: - https://git.kernel.org/stable/c/2f6ded79068cac8cff41d5d5632564165d98ee12 - https://git.kernel.org/stable/c/b702a1077b51fcb39507cc3bd39206f539319a96 - https://git.kernel.org/stable/c/0ac9c3dd0d6fe293cd5044cfad10bec27d171e4e
CVE ID: CVE-2022-49651 State: PUBLISHED Published: 2025-02-26T02:23:53.496Z Last Updated: 2025-05-04T08:42:35.988Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: srcu: Tighten cleanup_srcu_struct() GP checks Currently, cleanup_srcu_struct() checks for a grace period in progress, but it does not check for a grace period that has not yet started but which might start at any time. Such a situation could result in a use-after-free bug, so this commit adds a check for a grace period that is needed but not yet started to cleanup_srcu_struct(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/sta
ed to cleanup_srcu_struct(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/e997dda6502eefbc1032d6b0da7b353c53344b07 - https://git.kernel.org/stable/c/8ed00760203d8018bee042fbfe8e076579be2c2b
CVE ID: CVE-2022-49652 State: PUBLISHED Published: 2025-02-26T02:23:53.995Z Last Updated: 2025-10-01T19:36:48.365Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. Add missing of_node_put() in to fix this. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/452b9dfd7aca96befce22634fadb111737f22bbe - https://git.kernel.org/stable/c/61b4ef19c346dc21ab1d4f39f5c412e3037b2bdc - https://git.kernel.org/s
34fadb111737f22bbe - https://git.kernel.org/stable/c/61b4ef19c346dc21ab1d4f39f5c412e3037b2bdc - https://git.kernel.org/stable/c/3bd66010398871807c1cebacee07d60ded1b1402 - https://git.kernel.org/stable/c/b31ab132561c7f1b6459039152b8d09e44eb3565 - https://git.kernel.org/stable/c/37147e22cd8dfc0412495cb361708836157a4486 - https://git.kernel.org/stable/c/cb9813d7eae917acd34436160a278b8b5d48ca53 - https://git.kernel.org/stable/c/b5a817f8d62e9e13280928f3756e54854ae4962e - https://git.kernel.org/stable/c/c132fe78ad7b4ce8b5d49a501a15c29d08eeb23a
CVE ID: CVE-2022-49653 State: PUBLISHED Published: 2025-02-26T02:23:54.484Z Last Updated: 2025-10-01T19:36:48.233Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i2c: piix4: Fix a memory leak in the EFCH MMIO support The recently added support for EFCH MMIO regions introduced a memory leak in that code path. The leak is caused by the fact that release_resource() merely removes the resource from the tree but does not free its memory. We need to call release_mem_region() instead, which does free the memory. As a nice side effect, this brings back some symmetry between the legacy and MMIO paths. Additional Analyst Notes: - CISA AD
nice side effect, this brings back some symmetry between the legacy and MMIO paths. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/d2bf1a6480e8d44658a8ac3bdcec081238873212 - https://git.kernel.org/stable/c/a3263e4cf8265f0c9eb0ed8a9b50f132c7a42e19 - https://git.kernel.org/stable/c/8ad59b397f86a4d8014966fdc0552095a0c4fb2b
CVE ID: CVE-2022-49654 State: PUBLISHED Published: 2025-02-26T02:23:54.966Z Last Updated: 2025-05-04T08:42:39.271Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: dsa: qca8k: reset cpu port on MTU change It was discovered that the Documentation lacks of a fundamental detail on how to correctly change the MAX_FRAME_SIZE of the switch. In fact if the MAX_FRAME_SIZE is changed while the cpu port is on, the switch panics and cease to send any packet. This cause the mgmt ethernet system to not receive any packet (the slow fallback still works) and makes the device not reachable. To recover from this a switch reset is required. T
t (the slow fallback still works) and makes the device not reachable. To recover from this a switch reset is required. To correctly handle this, turn off the cpu ports before changing the MAX_FRAME_SIZE and turn on again after the value is applied. References: - https://git.kernel.org/stable/c/188c798f3c2554fa0d7147e9b97baf144b817019 - https://git.kernel.org/stable/c/1993f5a06736ada59dd54b50dc96755a38796ee5 - https://git.kernel.org/stable/c/386228c694bf1e7a7688e44412cb33500b0ac585
CVE ID: CVE-2022-49655 State: PUBLISHED Published: 2025-02-26T02:23:55.483Z Last Updated: 2025-05-04T08:42:40.760Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fscache: Fix invalidation/lookup race If an NFS file is opened for writing and closed, fscache_invalidate() will be asked to invalidate the file - however, if the cookie is in the LOOKING_UP state (or the CREATING state), then request to invalidate doesn't get recorded for fscache_cookie_state_machine() to do something with. Fix this by making __fscache_invalidate() set a flag if it sees the cookie is in the LOOKING_UP state to indicate that we need to go to invalidati
he_invalidate() set a flag if it sees the cookie is in the LOOKING_UP state to indicate that we need to go to invalidation. Note that this requires a count on the n_accesses counter for the state machine, which that will release when it's done. fscache_cookie_state_machine() then shifts to the INVALIDATING state if it sees the flag. Without this, an nfs file can get corrupted if it gets modified locally and then read locally as the cache contents may not get updated. References: - https://git.kernel.org/stable/c/b1ae9f617f8a5c848d9205b8e228c6f0d1af754b - https://git.kernel.org/stable/c/85e4ea1049c70fb99de5c6057e835d151fb647da
CVE ID: CVE-2022-49656 State: PUBLISHED Published: 2025-02-26T02:23:55.949Z Last Updated: 2025-10-01T19:36:48.099Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ARM: meson: Fix refcount leak in meson_smp_prepare_cpus of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/2e1bcd33478ef44e63a45457055060b5fe4118ad - https://git.kernel.org/stable/c/3cf8ece9113242c10f83c7675ea4f4f67959ee43 - https://git.kernel.org/stable/c
0b5fe4118ad - https://git.kernel.org/stable/c/3cf8ece9113242c10f83c7675ea4f4f67959ee43 - https://git.kernel.org/stable/c/3d90607e7e6afa89768b0aaa915b58bd2b849276 - https://git.kernel.org/stable/c/7208101ded1e9dcc52c8f0f8b16474211c871c1a - https://git.kernel.org/stable/c/c5fbf4f74c94fd60d5e9bf9f7f8268c3601562ca - https://git.kernel.org/stable/c/34d2cd3fccced12b958b8848e3eff0ee4296764c
CVE ID: CVE-2022-49657 State: PUBLISHED Published: 2025-02-26T02:23:56.417Z Last Updated: 2025-10-01T19:36:47.953Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usbnet: fix memory leak in error case usbnet_write_cmd_async() mixed up which buffers need to be freed in which error case. v2: add Fixes tag v3: fix uninitialized buf pointer Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/3eed421ca5c809da93456f69203d164d5220be3d - https://git.kernel.org/stable/c/5269209f54dd8dfd15f9383f3a3a1fe8370764f8 - https://git.kernel.org/stable/c/d5165e657987ff4ba0ace896d4376a3718a9fbc3 - https:/
09f54dd8dfd15f9383f3a3a1fe8370764f8 - https://git.kernel.org/stable/c/d5165e657987ff4ba0ace896d4376a3718a9fbc3 - https://git.kernel.org/stable/c/04894ab34faf40ab72a8a5ab5b404bb0606bbbff - https://git.kernel.org/stable/c/0085da9df3dced730027923a6b48f58e9016af91 - https://git.kernel.org/stable/c/db89582ff330556188da856e01382ccbf3a5e706 - https://git.kernel.org/stable/c/e7b4f69946a38209b4a4f660bf0e4cbed94f9b4b - https://git.kernel.org/stable/c/b55a21b764c1e182014630fa5486d717484ac58f
CVE ID: CVE-2022-49658 State: PUBLISHED Published: 2025-02-26T02:23:56.922Z Last Updated: 2025-05-04T08:42:44.420Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix insufficient bounds propagation from adjust_scalar_min_max_vals Kuee reported a corner case where the tnum becomes constant after the call to __reg_bound_offset(), but the register's bounds are not, that is, its min bounds are still not equal to the register's max bounds. This in turn allows to leak pointers through turning a pointer register as is into an unknown scalar via adjust_ptr_min_max_vals(). Before: func#0 @0 0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0
as is into an unknown scalar via adjust_ptr_min_max_vals(). Before: func#0 @0 0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) 1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) 2: (87) r3 = -r3 ; R3_w=scalar() 3: (87) r3 = -r3 ; R3_w=scalar() 4: (47) r3 |= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881) 5: (75) if r3 s>= 0x0 goto pc+1 ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 6: (95) exit from 5 to 7: R0=scalar(imm=1,umi
0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 6: (95) exit from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 7: (d5) if r3 s<= 0x8000 goto pc+1 ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 8: (95) exit from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0,imm=0
=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 9: (07) r3 += -32767 ; R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)) <--- [*] 10: (95) exit What can be seen here is that R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) after the operation R3 += -32767 results in a 'malformed' constant, that is, R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)). Intersecting with var_off has not been done at that point via __update_reg_bounds(), which would have improved the umax to be equal to umin. Refactor the tnum <> min/max bounds information flow into a reg_bounds_sync() helper and use it consistently
l to umin. Refactor the tnum <> min/max bounds information flow into a reg_bounds_sync() helper and use it consistently everywhere. After the fix, bounds have been corrected to R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) and thus the register is regarded as a 'proper' constant scalar of 0. After: func#0 @0 0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) 1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) 2: (87) r3 = -r3 ; R3_w=scalar() 3: (87) r3 = -r3 ; R3_w=scalar() 4: (47) r3 |= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xfffffffff